bug#73304: Python in relocatable guix pack leads to wrong sys.path

Konrad Hinsen writes: > I have changed my mind. In the sys.path outputs shown, there are no > paths from add-on packages. It's just the Python standard library. > Maybe our sitecustomize.py is not run at all, but if it is, it didn't do > anything to sys.path. There must b

bug#73304: Python in relocatable guix pack leads to wrong sys.path

Konrad Hinsen writes: > This problem clearly looks like it's caused by our sitecustomize.py. > One indicator is "When I add both python and a python package": if there > is no additional package, only python by itself, our sitecustomize > doesn't do anything.

bug#73304: Python in relocatable guix pack leads to wrong sys.path

Ludovic Courtès writes: > Rutherther skribis: > >> When I add both python and a python package (seems like any) to a >> relocatable guix pack, the resulting python in the merged profile seems >> to be broken. Specifically its `sys.path` contains missing paths. > Commit d5e0180805f52ef38a03ff9d6

bug#73475: Documentation for minify-build-system out of date

Hello everyone, While trying to figure out how to use the minify-build-system, I consulted the manual, compared it with the code, and concluded that the manual is probably out of date. It says: It adds @code{uglify-js} to the set of inputs and uses ... The code used esbuild rather than ug

bug#73295: TeX font maps are not reproducible

Hi everyone, The font maps generated during profile creation (procedure texlive-font-maps in guix/profiles.scm) are not reproducible: the order in which the files are listed in the ls-R file is not deterministic. As a consequence, files generated from profiles, such as Docker or Singularity conta

bug#72061: Discrepancy when running ‘guix pull’ from different machines

Hi Simon, > So IIUC, the channels.scm file you provided is not the same channels.scm > file here. You provided all the revisions to get this Guix and from > this Guix you tries to reach another revision (named channels.scm in the > above but just reads 7b0863f07a113caef26fea13909bd97d250b629e). >

bug#72061: Discrepancy when running ‘guix pull’ from different machines

Hi Simon, > Thanks. Do you know what the current Guix revision? It should have no > effect but who knows. :-) The "channels.scm" attached to my last message describes Guix at the time "guix time-machine" was launched. It's not the channels file used in the time machine command! That one is quit

bug#72061: Discrepancy when running ‘guix pull’ from different machines

HI Simon, > Could you share the channels.scm file? Attached. > Because the mention of ’guix-science’ means third-party channels, I > guess. And maybe there is something tricky when mixing different > specific pinned channels. I thought about that as well, but the behavior should still be the s

bug#72061: Discrepancy when running ‘guix pull’ from different machines

Hi everyone, Jumping in with a possibly related problem reported by a participant of the Reproducible Research MOOC. He gets an error when running an example from one of our exercises: guix time-machine --channels=channels.scm -- shell --container --network --manifest=manifest.scm -- jupyter

bug#68841: guix pack -f squashfs silently ignores symlinks

Let's make a basic Singularity file system containing certificates at the place many programs expect them to be, i.e. /etc/ssl: $ guix pack -S /etc/ssl=etc/ssl --format=squashfs bash nss-certs /gnu/store/mxyc56nsrcgcclvm5qsz5c9fkqwdswpw-bash-nss-certs-squashfs-pack.gz.squashfs There is no error m

bug#68794: git-annex accesses /etc/protocols

As packaged in Guix, git-annex reads the file /etc/protocols, e.g. for accessing Web remotes. This requires sharing this file from the host when running git-annex in a container. Other software in Guix is patched to use the protocols file from "net-base" instead. This should be done for git-annex a

bug#53258: Python unable to find modules within a Singularity container created with guix pack

Konrad Hinsen writes: > Patch at https://issues.guix.gnu.org/68241 If you want to test it without rebuilding tons of packages, here is a version that grafts a patched Python onto the existing ones (as substitutes): https://codeberg.org/khinsen/guix/src/branch/graft-fix-python-sitecustom

bug#53258: Python unable to find modules within a Singularity container created with guix pack

Konrad Hinsen writes: > I will submit a patch for this. Patch at https://issues.guix.gnu.org/68241 Cheers, Konrad

bug#53258: Python unable to find modules within a Singularity container created with guix pack

Hi everyone, I found this issue while investigating a related one (the error message). It looks like the core problem discussed here has been solved in the meantime: Singularity> python3 -m numpy Error in sitecustomize; set PYTHONVERBOSE for traceback: ValueError: '/gnu/store/kx98dz2vc3

bug#54350: Profile collisions in "guix shell"

Konrad Hinsen writes: > I run everything that is part of a research project in containers, > meaning "guix shell -C". Related: HPC users on clusters using NFS are also advised to use "guix shell" rather than profiles: https://lists.gnu.org/archive/html/guix-sci

bug#54350: Profile collisions in "guix shell"

Hi everyone, I ran into this issue when I was trying to turn a much-used shell environment into a profile for persisting the binaries in the store. I had been using it for several months, believing it to be OK. Fortunately it was easy to fix. Background: as part of a reproducible computation work

bug#57878: Emacs native compilation on startup can crash the system

Ludovic Courtès writes: > Konrad, Emacs team: is this bug still happening today? > > https://issues.guix.gnu.org/57878 I did some quick tests, and at least for my usage of Emacs, there are no more problems with native compilation in current Guix (including Emacs 29.1). Great! Konrad

bug#41394: java-testng: again nondeterministic test-failures?

During today's regular "guix pull", I ran into this problem: java-testng failed to build twice (the failures comes from the test suite), but built correctly the third time. That's for commit: 39fa1ef033fda82cb1d122e0d1675b51acb1db34 Cheers, Konrad.

bug#63726: time-machine without options does not get the latest commit

Hi Ludo, > I had forgotten about this issue (my apologies…) and stumbled upon it > again recently, which led me to approach it a bit differently: > > https://issues.guix.gnu.org/65229 > > Let me know what you think! This looks good to me. In practice, I doubt anyone would use -q with time-machi

bug#63726: time-machine without options does not get the latest commit

her than to a pinned commit. Cheers, Konrad. >From cbe372191a2daea7b62d8558422f08bc6ed0e047 Mon Sep 17 00:00:00 2001 From: Konrad Hinsen Date: Thu, 1 Jun 2023 16:55:33 +0200 Subject: [PATCH] doc: Reword guix time-machine without option. * doc/guix.texi (Invoking guix time-machine): Reword the behaviour in the absence of any opt

bug#63726: time-machine without options does not get the latest commit

Hi, > Should we fix the doc or should we fix the code?… I vote for fixing the doc. Two reasons: 1. Having "guix time-machine" and "guix pull" behave in the same way is desirable. Less cognitive load for users. 2. What the doc says cannot be implemented in general. "The latest commit o

bug#57878: Some further investigation

Hi everyone, On the occasion of a "guix pull", I looked into this issue again, because magit without ido-completing-read+ is less fun. Loading this package runs lots of compilation threads, but it does ultimately terminate, with an error: Debugger entered--Lisp error: (native-compiler-error (l

bug#57878: Minimal reproducible setup

Hi David and Liliana, Thanks David for the added observations. This does indeed look like an upstream bug, but it also seems to have a context dependence because the Debian bug reports list some packages are affected that cause no problem under Guix (e.g. git-timemachine). As for Liliana's idea o

bug#57878: Minimal reproducible setup

I did one more test: run native-compile by hand on each elisp file in the package ido-completing-read+. Works fine. The next question that I consider relevant: is this an upstream (Emacs) issue, or an issue created by packaging in Guix? That's not easy to answer. A related question: what are appr

bug#57878: Minimal reproducible setup

Liliana Marie Prikler writes: >> I think you can prevent native-compilation entirely by setting no- >> native-compile to t in your early-init.el (I'm playing with the idea >> of doing this anyway, because I'm annoyed by the clutter that falls >> through the cracks). > > Okay, it turns out that di

bug#57878: Minimal reproducible setup

Konrad Hinsen writes: > Here is a minimal containerized example that > creates a process avalanche: > > guix shell -C emacs emacs-ido-completing-read+ \ >-- emacs --batch --eval="(print load-path)" I went through all my emacs packages. The only one that sta

bug#57878: Minimal reproducible setup

My understanding of site-start.el is that it actually loads all the Emacs packages that are listed in my Guix profile. Which means that my package list matters. Here is a minimal containerized example that creates a process avalanche: guix shell -C emacs emacs-ido-completing-read+ \ --

bug#57878: Emacs native compilation on startup can crash the system

After updating to a commit after the introduction of native compilation in Emacs, I cannot start Emacs any more. It launches an ever increasing number of async processes for native compilation, which rapidly makes kswapd the main CPU user on my machine, and ultimately crashes the kernel. Some expe

bug#57136: Snakemake cannot execute remote jobs

The bug is fixed via the patch referenced above in commit 5831155175614726685edab7efa60ce48e4da1f5.

bug#57136: Snakemake cannot execute remote jobs

The other problem that Matthieu pointed out (but which is unrelated to the initial bug report) is fixed by the following two patches for snakemake-6 and snakemake-7: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57414 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57415 Cheers, Konrad

bug#57136: Snakemake cannot execute remote jobs

I have submitted a patch that fixes this problem: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57413 This is the patch that Matthieu referred to, and which he tested in a cluster environment. Cheers, Konrad

bug#57136: Snakemake cannot execute remote jobs

The execution of Snakemake workflows fails on a cluster because the script that Snakemake executes remotely does not reference Python correctly. This is due to a patch applied in the Guix package definition (build phase call-wrapper-not-wrapped-snakemake, https://git.savannah.gnu.org/cgit/guix.gi

bug#29736: i686: webkit not usable

Leo Famulari writes: > We can use the gst-plugins/selection procedure to avoid propagating all > of gst-plugins-bad. That sounds interesting. But we'd first have to know which plugins are actually important to have. Is there a way to trace plugin loading? Konrad

bug#29736: i686: webkit not usable

Am 05/01/2022 um 08:41 schrieb zimoun: Since the last message was from 2018 and, to my knowledge*, nothing related was reported recently, I am closing. For information, here's a lengthy discussion of WebKit crashes in the Nyxt browser when built under Guix: https://github.com/atlas-engineer

bug#52846: Fetching "texlive" substitute from ci.guix.gnu.org fails

Tobias Geerinckx-Rice writes: > Konrad Hinsen 写道： >> So... how did I overlook this when searching for "texlive" in >> the issue >> tracker? Answer: it doesn't sort correctly by "date submitted" >> when that >> column is selected. Issue

bug#52846: Fetching "texlive" substitute from ci.guix.gnu.org fails

Hi Tobias, > Is this ? Yes, same problem! So... how did I overlook this when searching for "texlive" in the issue tracker? Answer: it doesn't sort correctly by "date submitted" when that column is selected. Issue 52797 is way down on the list. Anyway, thanks f

bug#52846: Fetching "texlive" substitute from ci.guix.gnu.org fails

With $ guix describe Generation 11déc. 27 2021 11:45:02 (current) guix 879a5cb repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: 879a5cb7c45779ddd62699ae2d75a9e785d608ec do: $ guix shell texlive hint: Consider passing

bug#52093: Incorrect argument handling in "guix shell"

The following session illustrates that the -D option to "guix shell" is erroneously applied to *two* package arguments rather than just one if the first package argument takes the form of a file. The file "empty-package.scm" is attached, it defines an empty package with no inputs. The environment

bug#48376: Failure in "guix pull"

Hi Maxim, > I agree! We don't want people to send bug reports every time their > network is flaky, if this is indeed what has happened. Would you be > interested at surveying if that's the case in the current code? Perhaps > the right change would then become apparent. Interested, maybe, but I

bug#48376: Failure in "guix pull"

Hi Maxim, Thanks for your reply! > Indeed. I note that the error message that leads to a request to the > bug report mention it could be due to a network failure, which could > explain the transient nature of the problem we see here. > > Had you tried multiple times in a row with the same failur

bug#48376: Failure in "guix pull"

Trying the "guix pull" a short while (and one commit to Guix) later, the error is gone. Which is a bit strange: whatever the cause of the error was, it's hard to believe that adding the package "python-sqlalchemy-stubs" (which is what commit f8a4724c101880892640dcc2fe3438dc2a26b624 did) could fix i

bug#48376: Failure in "guix pull"

Today's "guix pull" resulted in an error message that ends with a request for a bug report. So here it comes: === Updating channel 'guix-past' from Git repository at 'https://gitlab.inria.fr/guix-hpc/guix-past'... Updating ch

bug#47239: Test failure in tests/publish.scm with commit 1955ef93b76e51cab5bed4c90f7eb9df7035355a

zimoun writes: > For the record, ’tests/publish.scm’ pass on Debian but not on Ubuntu. One more data point: the tests pass under Ubuntu 18.04, but fail under Ubuntu 20.04. Cheers, Konrad.

bug#47239: Test failure in tests/publish.scm with commit 1955ef93b76e51cab5bed4c90f7eb9df7035355a

Hi Ludo, > Is it reproducible? (You can run “make check TESTS=tests/publish.scm”.) Yes. > If it is, could you add ‘pk’ calls here and there to see which of the > sub-expressions in (and …) returns false? 'pk' shows nothing, but I rolled my own version using plain old "display" and found that

bug#47239: Test failure in tests/publish.scm with commit 1955ef93b76e51cab5bed4c90f7eb9df7035355a

Dear Guix Gurus, I am trying to compile Guix (commit 1955ef93b76e51cab5bed4c90f7eb9df7035355a) from source, on a computer running Ubuntu 20.04 with Guix added via a binary installation. I get one test failure, whose test-suite.log is attached. Cheers, Konrad. ==

bug#47190: Building git fails because of a hash mismatch

Léo Le Bouter writes: > Yes, this is fixed by 0ee5d4f7a8e25be437297f88ed7013c4f37abafb, simply > "guix pull", there's nothing we can do to the older commits. Thanks for the quick fix, this works fine indeed! Konrad

bug#47190: Building git fails because of a hash mismatch

With Guix commit (ab9629b7c91ff7d6392a03512cfe44282326), building git fails because of a hash mismatch when downloading the man pages (see log below). I'd be happy to submit a patch that updates the hash, but it's perhaps worth figuring out first what went wrong here. Konrad. building /gnu/

bug#26981: Bug report follow up

Hi Robert, >> > The bug: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26981 >> > If I don't hear back I'll assume it's safe to close this. >> >> Yes, it is. Thanks for doing a cleanup! > > This bug report is still relevant? Or are you saying that it is fixed? > Sorry if my email was a bit ambigu

bug#26981: Bug report follow up

Hi Robert, > Konrad, is this bug report still relevant? I suspect not, since it > seems to have been solved by switching to a more recent version > of guix 3 years ago. > The bug: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26981 > If I don't hear back I'll assume it's safe to close this. Yes,

bug#43331: guix repl doesn't find the script to execute

Hi Simon, > It sounds similar to the recent #42543 [1]. I proposed the fix [2] > using 'canonicalize-path' but Ludo was not fine with it and then > committed d10474c38d58bdc676e64336769dc2e00cdfa8ed [3]. Thanks for the references, all that happened while I was on vacation. There is indeed some

bug#43331: Patch

The patch that I just submitted fixes the problem. However, I don't really know what the cause of the bug is, given that load-in-vicinity is undocumented and I don't fully understand its implementation. So maybe there is a better way to fix this. Konrad.

bug#43331: [PATCH] repl: Look for script files in (getcwd).

* guix/scripts/repl.scm (guix-repl): Replace "." by (getcwd) --- guix/scripts/repl.scm | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/guix/scripts/repl.scm b/guix/scripts/repl.scm index 3c79e89f8d..80bf1460e9 100644 --- a/guix/scripts/repl.scm +++ b/guix/scripts/repl.scm @@ -1

bug#43331: guix repl doesn't find the script to execute

Example: $ guix repl moocrr_guix_jupyter/installed-dependencies.scm Backtrace: 1 (primitive-load-path "./moocrr_guix_jupyter/installed-d…") In ice-9/boot-9.scm: 1669:16 0 (raise-exception _ #:continuable? _) ice-9/boot-9.scm:1669:16: In procedure raise-exception: In procedure primit

bug#39079: SBCL CFFI from Guix unable to find dynamic libraries

Pierre Neidhardt writes: > Which "ldd" did you use? Ubuntu's or Guix'? > Where did you run it? Good suggestion. My expectation is that Evan used Ubuntu's ldd, and that using Guix' will show different results. > Try exporting LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu in the > environment in whi

bug#39079: SBCL CFFI from Guix unable to find dynamic libraries

Pierre Neidhardt writes: > Konrad Hinsen writes: > >> Note that this is a feature, not a bug, so if that's the cause of the >> problem, there is nothing to do about it. You'd have to compile sbcl >> with the toolchain of the foreign distro. > > You don&

bug#39079: SBCL CFFI from Guix unable to find dynamic libraries

Hi Pierre and Evan, This seems to be a red herring, as Guix does not change how CFFI loa > libraries. The only thing that changes is where the libraries are found> with Guix packages. I don't know about the details of SBCL and its CFFI, but there is a difference in how Guix handles shared lib

bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism

Hi Ricardo, > I wonder if we should simply bump the version number to indicate that > this is a breaking change? That's a possibility, but who ever looks at Guix version numbers? > Another more difficult option would be to do what responsible API > developers on the web do: to version their API

bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism

Hi Simon, > Assuming "guix environment" would stay and following the proposed > plan, you would need to add GUIX_ENVIRONMENT_DEPRECATED=1 on the top > of your script. In this would not be a problem for travelling back in > time. The problem is not how I update my scripts - I can manage that, no m

bug#38529: Deprecating ‘guix environment’?

Hi Ludo, > Clearly there’s a tension between that and keeping Guix open to changes. That's indeed the main problem and here as elsewhere, it is often a topic of heated arguments. My point of view (long form: https://hal.archives-ouvertes.fr/hal-02117588) is that software projects should adopt a

bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism

Hi Simon, > Maybe I miss a point. It is not: "watch out, this will do something > else in the future" but "watch out, this was doing something else in > the past and the change happened the in ". Concrete example: I am writing a tutorial about using Guix for reproducible research. It shows sever

bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism

On 16/12/2019 23:09, Ludovic Courtès wrote: So in a more algorithmic manner: 1. if ad-hoc and inputs-of is present at the same invocation: fail hard. (With an error like incompatible options present) 2. if only ad-hoc is present, then print a deprecation warning (yes, we could make this suspenda

bug#38568: Org Mode (as a dependency) is borked

Hi Jelle, > Byte-compiling the org-jira.el file manually gives an .elc file without > a reference to `org-outline-overlay-data'. This leads me to believe that > the previously posted fix for #38479 could be extended to make sure > Emacs' built-in packages are at the trailing end of EMACSLOADPATH,

bug#30961: Byte compilation problem with emacs-org

Hi Maxim, > Does this still occur on latest master? No, the bug disappeared with the update to Emacs 26.3, which comes with org-mode 9. So this bug report can be closed (which I'd have done already if I knew how to do it). Cheers, Konrad

bug#38277: biber 2.12 fails to build

Hi Guix, There is a build failure with biber 2.12 in current Guix (commit 7b40d59114e1462d6d8140f325a66b12e91db667). The build log is attached, it shows that several tests fail. Note that I tried to update to biber 2.13, which builds without problems, but I then discovered that it is not compatib

bug#37989: python2-numpy v0.17.3 fails to build

Hi Josh, Lots of packages including libreoffice transitively depend on python2-numpy, so this needs some sort of resolution — perhaps simply pinning python2-numpy to a previous version? That would be my preferred solution - pin python2-numpy to the last NumPy version that supports Python 2, wh

bug#37505: "make check" fails on a fresh Guix checkout

Konrad Hinsen writes: > Konrad Hinsen writes: > >> Unfortunately, a very similar error still blocks compiling a fresh Guix >> checkout: > > Sorry, false alarm. I have been typing in the wrong terminal window. OK, I triple-checked: there still is a problem. There are two

bug#37505: "make check" fails on a fresh Guix checkout

Konrad Hinsen writes: > Unfortunately, a very similar error still blocks compiling a fresh Guix > checkout: Sorry, false alarm. I have been typing in the wrong terminal window. Too many Guix installations in my life ;-) Konrad.

bug#37505: "make check" fails on a fresh Guix checkout

Ludovic Courtès writes: > Konrad Hinsen skribis: > >> e...@boldquot.po:2849: format specifications in 'msgstr[0]' are not a subset >> of those in 'msgid_plural' >> e...@boldquot.po:2856: format specifications in 'msgstr[0]' are not

bug#37357: Is there a workaround?

Konrad Hinsen writes: > I suspect that I am a victim of this bug as well. Is there a workaround? > I tried removing next, doing another gc to get a clean slate, and then > re-installed next. But it still complains that it can't find the > next-gtk-webkit executable. This actua

bug#37357: Is there a workaround?

I suspect that I am a victim of this bug as well. Is there a workaround? I tried removing next, doing another gc to get a clean slate, and then re-installed next. But it still complains that it can't find the next-gtk-webkit executable. Konrad.

bug#37505: "make check" fails on a fresh Guix checkout

Hi everyone, on a fresh checkout of today's Guix master branch (commit b150e83bef766ca67a3931afce36b6cb6c7f8c10), "make check" fails due to problems with the po files. Log below. Konrad. GEN doc/os-config-bare-bones.texi GEN doc/os-config-desktop.texi GEN doc/os-config-light

bug#34998: "guix pull" fails because it cannot build a derivation

Hi Ricardo, >> Today's "guix pull" ended in a failure that I am supposed to report, so >> here I do! > > This has already been fixed. Please try again! I had done so after reading Ludo's comment, and it works fine now! Thanks, Konrad.

bug#34998: "guix pull" fails because it cannot build a derivation

Dear guix team, Today's "guix pull" ended in a failure that I am supposed to report, so here I do! Konrad. $ guix pull Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'... Building from this channel: guix https://git.savannah.gnu.org/git/guix.gi

bug#33368: "guix archive" fails because of guix-authenticate

l...@gnu.org (Ludovic Courtès) writes: > Oops, this is fixed in commit 7a54b2281d1f60fd0ae2e058c219c5a600ad756b > (the next commit, 0fe1fba4af41f267c4bb2c006fb37f42422ab703, changes Guix > itself so that the script is installed as LIBEXECDIR/guix/authenticate, > for consistency.) > > To test it, y

bug#33368: "guix archive" fails because of guix-authenticate

Hi Ludo and Ricardo, > Could you strace the daemon and then re-run the command? > > sudo strace -p $(pidof guix-daemon) -f -o daemon.log -s 234 > guix archive --export sed > /dev/null > > I tested and it works for me, so we’ll have to see what’s going wrong > behind the scenes. With the strac

bug#33365: Package 'direnv' fails to build

Am 13.11.18 um 17:29 schrieb Leo Famulari: Fixed in commit 978d59737acaadbb0d2aa02ed071bb5d3f555973, which specifies that Go 1.9 should be used. Wow, that was quick! Thanks, Konrad.

bug#33368: "guix archive" fails because of guix-authenticate

Dear Guix maintainers, With guix current as of today (commit d5401375099f6e4562b849121265bb1c3e85874f), I cannot produce nar archives because of a failure of guix-authenticate. Demonstration: $ guix archive --export git > git.nar guix archive: error: build failed: program `guix-authenticate'

bug#33365: Package 'direnv' fails to build

Dear Guix maintainers, after today's "guix pull", I could not update my profile because the tests of package "direnv" fail. The relevant part of the build log is attached below. This looks like it might be related to the recent update of Go to 1.11. Cheers, Konrad. starting phase `check' go t

bug#32183: New ‘guix pull’ /root/.config/current/bin/guix: Permission denied

Hi Ludo, > To work around it, you can pull from an older generation, along these > lines: > > ~/.config/guix/current-42-link/bin/guix pull > > (This will work because this older guix won’t attempt to move your > generations to /var/guix/profiles, so it allows you to “jump over” the > bug.) > > L

bug#32183: New ‘guix pull’ /root/.config/current/bin/guix: Permission denied

Hi Ludo, > If you’re familiar with Dired in Emacs, I’d suggest opening > /var/guix/profiles/per-user/root and fixing the symlink targets from > there (with C-c C-q). Done. And after rebooting, guix seems to work fine for root, including the download phase. Meaning that I consider this bug fixed.

bug#32183: New ‘guix pull’ /root/.config/current/bin/guix: Permission denied

Hi Ludo, Hmm you might need to run, say, ‘guix pull -l’, to make this script magically appear. :-) Concretely, the new ‘guix pull’ migrates things from ~/.config/guix to /var/guix/profiles the first time you run it, but it may be that you haven’t yet run the *new* ‘guix pull’. That looks lik

bug#32183: New ‘guix pull’ /root/.config/current/bin/guix: Permission denied

Hi Ludo, I believe commit ed9d7cb4d95f8f4776e6fee2778ab52bc2852969 fixes it. That is, if you run ‘guix pull’ as root and then start ~/.config/guix/current/bin/guix-daemon, everything should be fine. Let's say the bug seems to be elsewhere now ;-) When I try to build something after following y

bug#32183: New ‘guix pull’ /root/.config/current/bin/guix: Permission denied

Hi Ludo, > I don’t think you’re doing anything wrong. Could anyone of you who > experience this problem strace guix-daemon? I’ve thought about this and > don’t understand where that EACCES (“Permission denied”) comes from. > > Specifically, you’d have to run something along these lines as root:

bug#32183: Me too!

Hi Ludo and Pjotr, I just ran into this bug as well: ./pre-inst-env guix build python-matplotlib @ build-started /gnu/store/33hf690qiwrvr0y59g9xwz6rpf3mmbj6-matplotlib-2.2.3.tar.gz.drv - x86_64-linux /var/log/guix/drvs/33//hf690qiwrvr0y59g9xwz6rpf3mmbj6-matplotlib-2.2.3.tar.gz.drv.bz2

bug#22629: “Stable” branch

Hi Ludo, > What do you mean by “limit it to channels”? ‘%default-channels’ is an > alias for the official Guix channel (IOW, Guix itself.) Fine, but I rarely care about all of Guix, or all of any other channel. I care about the small subset of packages that I actually use. Better yet, with a pe

bug#32022: bug#22629: “Stable” branch

Hi Ludo, > I just had a bright idea (yes!): this can be addressed by writing > something like this in ~/.config/guix/channels.scm: > > (map latest-commit-with-substitutes-available >%default-channels) > > The hypothetical ‘latest-commit-with-substitutes-available’ would use > (git) and (

bug#22629: “Stable” branch

Hi Ludo and Alex, l...@gnu.org (Ludovic Courtès) writes: > These are all things that very rarely, if ever, changed over the last 5 > years. I expect the change rate to remain the same. :-) That's reassuring! > You seem to be arguing of a “stable” branch in the sense that the Guix > tools (th

bug#22629: Channels not needed for a stable branch

Hi Mark, > I'm not sure what you're trying to argue above. To me, it looks like an > argument in favor of my position, namely that a stable version of Guix > should include _all_ of Guix, not just the packages. All, probably not, some, probably yes. What I am arguing is that the productive coexi

bug#22629: Channels not needed for a stable branch (was: Channels!)

Hi Ricardo, > I also agree with you that we don’t need channels for providing a stable > branch. The biggest obstacle to providing a stable branch is not > technical, but it requires people maintaining it. Look at this from the opposite end: if you were interested in maintaining a stable softwar

bug#22629: Channels!

Hi Ludo, > Mark’s concern is not about whether packages are the latest version, > etc. It’s about the constraints that could result from widespread > development of channels outside Guix proper: technically all of Guix is That's how I understood it as well. If/when Guix becomes somebody else's d

bug#22629: Channels!

Hi Mark, I'd like to say again that I have grave concerns that this could be the > death-knell for long-term innovation in Guix. It's likely that whenever> a change is proposed that will break these third-party channels, there> will be resistance, and efforts to preserve backward compatibilit

bug#32316: Thanks!

Hi Julien, I missed your reply because it arrived while I was on vacation, so I was made aware of it only by the message about the bug being closed. Thanks for your clear explanation, I will uninstall guix from my profile! Konrad.

bug#30680: [PATCH] Patch Racket to fix bug #30680

is indeed fixed. BTW, the patch (to Guix) for updating Racket to 7.0 is at https://debbugs.gnu.org/32355 (but does not yet include this patch to Racket). Thanks a lot for resolving this issue! Konrad. >From da6defb46b69dfb55e5188ed851f5c1443f748ba Mon Sep 17 00:00:00 2001 From:

bug#32316: Build failure with installed guix that does not happen with pre-inst-env

Hi Björn, > thanks for the precise error report. Thanks for your quick reply! > Could it be the case that in your `guix build ...` you are not using > the guix you pulled? > > What does `guix --version` say? > > Where does `which guix` point to? > > It should point to > > ~/.config/guix/current/

bug#32316: Build failure with installed guix that does not happen with pre-inst-env

Dear Guix experts, When updating my Guix installation after three weeks of absence, I noticed a build failure: $ guix pull –commit=de596e99549d7764f370ab2ed3b756f620b1f23d $ guix build racket guix package: error: racket-fix-xform-issue.patch: patch not found However, that patch file is

bug#30921: Jupyter uses the wrong Python.

l...@gnu.org (Ludovic Courtès) writes: >> Yes. Installed kernels are normally under $prefix/share/jupyter/kernels. >> A standard installation of Jupyter via PyPI also installs a kernel for >> the same Python interpreter that is used for Jupyter. Additional kernels >> can then be installed afterwar

bug#22629: [PATCH 0/4] 'guix pull' produces a self-contained Guix

Hi Ludo, >> Fine, so if I run update-guix-package.scm and then do the install, I get >> what I expect, right? > > Yes (even with current ‘master’), but it’s quite heavyweight since you > end up recompiling all of Guix. Not great, but doable from time to time. >> I am looking for a reasonably str

bug#22629: [PATCH 0/4] 'guix pull' produces a self-contained Guix

Hi Ludo, >> Just wondering: does this mean that I could substitute Guix from my local >> source tree simply by doing >> >>./pre-inst-env guix package -p ~/.config/guix/current -i guix > > That would just install the snapshot that the ‘guix’ package refers to > (it’s defined in (gnu packages pa

bug#22629: [PATCH 0/4] 'guix pull' produces a self-contained Guix

Hi Ludo, > The major difference is that instead of just building a bunch of modules > and putting them under ~/.config/guix/latest, it now produces a > standalone package (with bin/guix, share/info/guix.info, etc.) and puts > it in a profile under ~/.config/guix/current. Quoth the manual: This s

bug#30961: Byte compilation problem with emacs-org

Konrad Hinsen writes: > I tried to remove the old org-mode from load-path during byte > compilation of the new version by manipulating EMACSLOADPATH, so far > without success. If Emacs' basic "lisp" dir is not on EMACSLOADPATH, I managed to do this in the end, and it do

  1   2   >