Hi,
> doesn’t look like a Guix issue right now (well, we
> could catch the exception). I reported the issue here:
> https://github.com/commercialhaskell/stackage/issues/7769 – not sure
> whether this is the correct place.
this has been fixed upstream and in commit
a5768ec09332a625c709a20f76f0227a
on-invalid" error to commit
> 0bce74d458a343e61d054c4b25d6f67bd1086f3c "gnu: Upgrade to Stackage 20.26."
> from early June of last year. I've CC'ed Lars-Dominik Braun since he was the
> author of the stackage update commit.
doesn’t look like a Guix issue right now (w
Hi,
> It looks like we still take info from ‘requirements.txt’; is
> ‘pyproject.toml’ insufficient?
correct. As a first quality of life improvement I would keep the other
information sources, but as we improve the importer further (by adding
poetry support for example), we need to fall back on th
(we need a different
version parser for that), but it’s a start.
Lars
>From c2e7e07ad407613233edbb7ebfcc6f0c7c0bcc25 Mon Sep 17 00:00:00 2001
Message-ID:
From: Lars-Dominik Braun
Date: Sun, 15 Dec 2024 13:22:00 +0100
Subject: [PATCH 1/4] import: pypi: Support extracting dependencies from
py
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
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
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
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
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
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.gui
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 wheth
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
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
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 reference
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
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 a
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
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
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 wor
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',
Hi,
I discovered this issue independently and fixed it in commit
3d05d549184d5399d2949535cf5cad8b92b263dd.
Cheers,
Lars
eibniz-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
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-overw
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
/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/R
dress 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
Uni
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-Y7nuUr9RcCC0rgE
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'
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
None of these are actual errors, but warnings. I’ve built a ton of
Haskell packages and never encountered transient errors.
GHC 8.8 is not the default any more.
Not applicable to GHC 9.2 any more.
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 Inst
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
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
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
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
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 (primiti
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
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 arg
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 up
Hi,
this issue has been fixed in commit dedfcaa8e2b948124f76121b9062c827fe649e29.
Cheers,
Lars
Hi,
fix pushed to master in commit 2c5d18e421e6c06f4a969f98585ec41aae8eb2e4.
Cheers,
Lars
Hi,
fix pushed to master as c3fbaee34548fbfb1617dc7fccc94c598efbd7a6 and following.
Cheers,
Lars
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 texliv
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 ex
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
> envir
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
hc-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-Domi
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 modu
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, scra
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
` 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:
5 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 procedur
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
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 prob
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
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
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
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 b3
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 b
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
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
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 tr
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
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/xbxrx9yqgqbv6949g
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 d
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).
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.
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
Hi,
this was fixed by the patch from #50588.
Cheers,
Lars
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
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 trie
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---
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 redownloa
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 dep
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 ba
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
aph “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-
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 def
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. Th
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
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
$ t
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 do
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/packa
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 a
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
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
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
>
> I
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?
lookin
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
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
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
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 pipel
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-i
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 a
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
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 an
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 f
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
> s
1 - 100 of 102 matches
Mail list logo
