bug#57559: guix pull fails on http status code 503
André A. Gomes writes: > Hi Guix, > > $ guix pull > Updating channel 'nonguix' from Git repository at > 'https://gitlab.com/nonguix/nonguix'... > guix pull: error: Git error: unexpected http status code: 503 > > It seems reasonable that if a certain channel isn't available, it should > be possible to ignore it and proceed. Hi Guix, In the same spirit as the report above, invoking guix pull replied: --8<---cut here---start->8--- Updating channel 'nonguix' from Git repository at 'https://gitlab.com/nonguix/nonguix'... Updating channel 'aadcg' from Git repository at 'https://github.com/aadcg/aadcg-guix-channel'... Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'... guix pull: error: Git error: unexpected http status code: 502 --8<---cut here---end--->8--- I'd would be helpful to see which channel failed and continue the operation with the channels that are operational. Thanks. -- André A. Gomes "You cannot even find the ruins..."
bug#69487: Regression regarding guix shell and its "pure" flag?
Hi Guix, Take a package that you have installed in the default profile, say "which". Then notice that when issuing "guix shell --pure" followed by "which which" replies that the command can't be found. On the other hand, when starting the environment via "guix shell", the command can be found. If my memory isn't tricking me, the "pure" flag used to behave differently. It simply started the shell with a clean env, but it still exposed the packages from the default profile. Am I missing something or is this a regression? Thanks. -- André A. Gomes "You cannot even find the ruins..."
bug#57543: Update
Fixed in the mean time. -- André A. Gomes "You cannot even find the ruins..."
bug#64014: guix pack regression
Ludovic Courtès writes: > Yes, that’d be great. If you still have that older pack that didn’t > have the problem, you could also run it under ‘strace -f -o > /tmp/log.strace’ to see what happens before the failure. Ludovic, I didn't reach any meaningful conclusion. Please close this issue. Thanks. -- André A. Gomes "You cannot even find the ruins..."
bug#64014: guix pack regression
Ludovic Courtès writes: > I suppose you might get this is you do ‘guix pack -R bubblewrap’ and > then try to run ‘bwrap’ from that pack: the ‘bwrap’ executable already > runs in a separate user namespace and might be unable to create one (?). Hi Ludovic, Thanks for the answer. You've helped me to figure it out. The guix pack I've created has webkitgtk in it, which in turn uses bubblewrap. However, I didn't have this issue in the past. It could be that webkitgtk changed something in their logic perhaps. I'd have to look deeper. Another strategy would be to try to reproduce your recipe in an older Guix version to see what happens (guix pack -R bubblewrap followed by bwrap). -- André A. Gomes "You cannot even find the ruins..."
bug#64014: guix pack regression
Hello Guix, I've produced a guix pack with the same command that I've always used (which includes passing the -RR flag), but I now get the following message: --8<---cut here---start->8--- bwrap: No permissions to creating new namespace, likely because the kernel does not allow non-privileged user namespaces. On e.g. debian this can be enabled with 'sysctl kernel.unprivileged_userns_clone=1'. --8<---cut here---end--->8--- Any ideas? Thanks. Guix version: --8<---cut here---start->8--- guix f36b8a9 repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: f36b8a9763087d2b9d3705595fbc34b054297ab8 --8<---cut here---end--->8--- -- André A. Gomes "You cannot even find the ruins..."
bug#63394: guix pack and proot
Hi Guix,
I acknowledge the answers provided, but I'd like to emphasize that guix
pack won't run if proot is broken. This is a critical issue and a
temporary solution is simple enough: disable the tests for the current
proot version packaged.
Please check the patch attached.
--
André A. Gomes
Atlas Engineer - https://atlas.engineer/
>From 1c9ece50575f568c824be2274b7b4d874827f0bb Mon Sep 17 00:00:00 2001
From: "Andre A. Gomes"
Date: Mon, 29 May 2023 16:02:45 +0300
Subject: [PATCH] Fix proot.
---
gnu/packages/linux.scm | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index 1be505d949..01f809d980 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -8212,12 +8212,9 @@ (define-public proot
(supported-systems '("x86_64-linux" "i686-linux"
"armhf-linux" "aarch64-linux" "i586-gnu"))
(arguments
- ;; Disable the test suite on armhf-linux, as there are too many
- ;; failures to keep track of (see for example:
- ;; https://github.com/proot-me/proot/issues/286).
- `(#:tests? ,(not (or (%current-target-system)
- (string-prefix? "armhf"
- (or (%current-system)
+ ;; Temporarily disable the tests until https://issues.guix.gnu.org/63284
+ ;; is solved.
+ `(#:tests? #f
#:make-flags '("-C" "src")
#:phases (modify-phases %standard-phases
(add-after 'unpack 'patch-sources
--
2.39.2
bug#63394: (no subject)
race00 ok
CHECK test-ptrace01 ok
CHECK test- ok
CHECK test- ok
CHECK test- ok
CHECK test- ok
CHECK test-e87b34ae ok
CHECK test- ok
CHECK test- ok
CHECK test- ok
CHECK test-cdd39012 ok
CHECK test-gdb-ptrace ok
--8<---cut here---end--->8---
--
André A. Gomes
"You cannot even find the ruins..."
>From b1046b937fd4b15ff7a78cc725c300694271e5ed Mon Sep 17 00:00:00 2001
From: "Andre A. Gomes"
Date: Tue, 9 May 2023 21:32:25 +0300
Subject: [PATCH] gnu: proot: Update to 5.3.1.
* gnu/packages/linux.scm (proot): Update to 5.3.1.
---
gnu/packages/linux.scm | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index ea64e9d241..acb8cd66e1 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -8143,7 +8143,7 @@ (define-public ulogd
(define-public proot
(package
(name "proot")
-(version "5.3.0")
+(version "5.3.1")
(source
(origin
(method git-fetch)
@@ -8152,19 +8152,14 @@ (define-public proot
(commit (string-append "v" version
(file-name (git-file-name name version))
(sha256
-(base32 "1r1ga3xbwq5kx4i8ihj1p6nmgaa14lfkwxzpsbdcmfh1jimpbmzk"
+(base32 "18455hni05nn3jyy8qfk1xwx0rd6s1qn9np1b61hkfb36b0gbpdq"
(build-system gnu-build-system)
;; Many architectures are not supported (see:
;; https://github.com/proot-me/proot/blob/master/src/arch.h#L51).
(supported-systems '("x86_64-linux" "i686-linux"
"armhf-linux" "aarch64-linux" "i586-gnu"))
(arguments
- ;; Disable the test suite on armhf-linux, as there are too many
- ;; failures to keep track of (see for example:
- ;; https://github.com/proot-me/proot/issues/286).
- `(#:tests? ,(not (or (%current-target-system)
- (string-prefix? "armhf"
- (or (%current-system)
+ `(#:tests? #f
#:make-flags '("-C" "src")
#:phases (modify-phases %standard-phases
(add-after 'unpack 'patch-sources
--
2.39.2
bug#63394: Unable to build proot-static locally
Hello Guix, I'm unable to build proot-static locally. The build job seems to idle for many hours and never succeeds. Notice that this critical, since guix pack relies on this package. --8<---cut here---start->8--- guix a759cbf repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: a759cbffafbf67b3a03c80b5bdbe3f3478affc50 --8<---cut here---end--->8--- Thank you! -- André A. Gomes "You cannot even find the ruins..."
bug#62415: Bump %webkit-version
Hi Guix, Web browsers relying on webkitgtk version 2.38.5 (such as Nyxt, Epiphany or Surf) suffer from serious bugs when using this concrete webkitgtk version. For instance, accessing github.com results in a blank page. I'd suggest either downgrading to 2.38.4 or bumping to 2.40.0. Notice that the latter is the most up-to-date stable release, see https://webkitgtk.org/2023/03/17/webkitgtk2.40.0-released.html My machine is not very powerful and I'm not sure whether it'll handle a local build so that I can make the necessary checks and send a patch. Could someone please help? Thanks. -- André A. Gomes "You cannot even find the ruins..."
bug#57543: emacs-telega is broken
Giovanni Biscuolo writes: > Hi André > > I was able to swith back to a previous profile generation and use > emacs-telega again, see below Hi Giovanni! It's working for me too, following your steps! So, I believe we're agreeing that the commit we referred to should be reverted. Correct? Thanks. -- André A. Gomes "You cannot even find the ruins..."
bug#57543: emacs-telega is broken
Giovanni Biscuolo writes: > I did it: i switched (--switch-generation=) my profile to a previous > generation (when emacs-telega was running) and telega-server > (automatically started by telega) is not starting anymore, with the > error I reported in my previous message > > André please could you try to switch back to a previous profile > generation and test it, reporting the errors you get in Emacs *Messages* > buffer in ~/.telega/telega-server.log (unless you configured another > telega directory)? Hi Giovanni, I switched back to a previous profile generation and I was able to start the telega server only after deleting all database files located at ~/.telega/. Before doing that I was also getting errors. Some things look off in in *Telega Root* buffer tough, and I can't use emacs-telega as before. I can't say it's working properly. Does this make sense? Can you reproduce what I've detailed? Thanks. -- André A. Gomes "You cannot even find the ruins..."
bug#57543: emacs-telega is broken
Giovanni Biscuolo writes: > AFAIU when I ran telega with the new tdlib verson, the database got > upgraded and the new database version is not compatible with the old > tdlib library; there is an old (Mar 2021) telega.el issue that helped me > understand this one: https://github.com/zevlg/telega.el/issues/276 > > If I'm not getting it wrong, reverting the "offending" patch and > restoring tdlib to 1.8.0 is not enough for people like us who already > upgraded tdlib (and started telega), we need to restore from backups. Hi Giovanni, Great investigation, thanks. I'm a bit confused when you say "restore from backups". Are you saying that, for those who have already upgraded tdlib, it's not sufficient to simply switching to an older generation? -- André A. Gomes "You cannot even find the ruins..."
bug#57543: emacs-telega is broken
Giovanni Biscuolo writes: > Currently packaged emacs-telega is v.0.8.03, the > telega-tdlib-max-version defined for that version is "1.8.0" [1] > > The latest version of telega.el in master (defined as Version 0.8.44 in > metadata) [2]: it does support tdlib 1.8.4, but unfortunately uspream is > not releasing (via git tag) since v.0.8.03: should we use the commit > hash c547477be39298eabf8e67f0116a115771f2ee0b to upgrade emacs-telega to > the last upstream version? > > Meanwhile, since tdlib now is only used by emacs-telega[-server] we > should temporary revert this commit, unless there are security concerns. > > WDYT? Hi Giovanni, Thanks for investigating. I think you're right. Either reverting or updating the emacs-telega package definition (needs to be tested still). I'd revert it right away, since it's broken as of now. I don't have commit access. Ludovic, could you please do it? Thanks. -- André A. Gomes "You cannot even find the ruins..."
bug#57559: guix pull fails on http status code 503
Maxime Devos writes: > More concretely: > > * if all channels are available --> ok, keep status quo > * if no channels are available --> error, keep status quo > * if some but not all channels are available, and there is at least one > updated channel --> log the missing channels, and update the channels > that _are_ available (but don't 'ignore' the missing channels by > removing them!). > * if some but not all channels are available, and none of the available > channels were updated --> bail out, no progress was made and this > might be due to lack of connectivity instead of lack of updates. > > ? > > Technically, your message can be interpreted as: if I only have a single > channel, the Guix channel, and it isn't available, it should be possible > to ignore it and proceed. (Proceed with what? It's the only channel, > what is there to proceed with.) To actually implement this, we need to > be precise. I'm just a user and unfortunately I don't have a deep understanding of Guix's internals. Your concrete description seems to resonate with my expectations. Thanks. -- André A. Gomes "You cannot even find the ruins..."
bug#57559: guix pull fails on http status code 503
Hi Guix, --8<---cut here---start->8--- $ guix pull Updating channel 'nonguix' from Git repository at 'https://gitlab.com/nonguix/nonguix'... guix pull: error: Git error: unexpected http status code: 503 --8<---cut here---end--->8--- It seems reasonable that if a certain channel isn't available, it should be possible to ignore it and proceed. Thanks. -- André A. Gomes "You cannot even find the ruins..."
bug#57543: emacs-telega is broken
Hi Guix, The latest emacs-telega raises the following warning: --8<---cut here---start->8--- Warning (emacs): TDLib version=1.8.4 > 1.8.0 (max required), please downgrade TDLib and recompile ‘telega-server’ Disable showing Disable logging --8<---cut here---end--->8--- Please revert the following commit: --8<---cut here---start->8--- 80df3ffb4fba19c9711ca912503df01cd2c9dc96 Author: Zhu Zihao AuthorDate: Sat Aug 6 23:12:17 2022 +0800 Commit: Ludovic Courtès CommitDate: Thu Sep 1 00:57:10 2022 +0200 --8<---cut here---end--->8--- Thanks. -- André A. Gomes "You cannot even find the ruins..."
bug#55459: Acknowledgement (Emacs 28.1 and its manual)
All good. Not sure exactly what happened. -- André A. Gomes "You cannot even find the ruins..."
bug#55391: Multiple slim services
bug#55391: Multiple slim services
Carlo Zancanaro writes: > Hi André, > > On Mon, May 16 2022, André A. Gomes wrote: >> Here it goes. The manual states that you can have two slim services >> on different ttys. Am I misinterpreting something? Thank you! > > I don't think you're misinterpreting anything, but Josselin is correct > when they say > > On Fri, May 13 2022, Josselin Poiret wrote: >> If I understand the relevant code properly, this should happen only >> when you try to extend a service type (eg. slim-service-type) with >> another service > > In your case, you're using set-xorg-configuration which tries to extend > your slim-service-type service. Unfortunately, you want to define two of > them, which causes the extension mechanism to fail complaining about the > ambiguity. > > You should be able to fix this by adding the xorg-configuration directly > into the slim service that you're defining, something like this: > >(cons* (service slim-service-type (slim-configuration > (display ":0") > (vt "vt7") > (xorg-configuration >(xorg-configuration > (modules (list > xf86-input-libinput > xf86-input-evdev >xf86-input-wacom)) > (keyboard-layout > keyboard-layout) > (server-arguments > ;; disable screen-saver > timeout > (append (list "-s" "0") > > %default-xorg-server-arguments)) > (extra-config (list > xorg-touchpad > xorg-monitor)) > (service slim-service-type (slim-configuration > (display ":0") > (vt "vt8") > ;; I wasn't sure if you > wanted the same > ;; xorg-configuration here, > so I left it out. > )) > (modify-services %desktop-services > (delete gdm-service-type) > (delete (screen-locker-service xlockmore "xlock" Hi Carlo Zancanaro, It all makes sense now! I really appreciate your help, thanks :) -- André A. Gomes "You cannot even find the ruins..."
bug#55391: Multiple slim services
Josselin Poiret via Bug reports for GNU Guix writes:
> Hello André,
>
> André A. Gomes writes:
>
>> Hi Guix,
>>
>> The manual (see (info "(guix) X Window")) mentions that it's possible to
>> add two slim services but it seems not to work. When I tried to
>> reconfigure the system it gives the following error:
>>
>> --8<---cut here---start->8---
>> guix system: error: more than one target service of type 'slim'
>> --8<---cut here---end--->8---
>
> If I understand the relevant code properly, this should happen only when
> you try to extend a service type (eg. slim-service-type) with another
> service, but you have multiple instances of the given service type, and
> so guix system can't disambiguate between the two (it would be better if
> you could manually specify that imho, but alas). Could you post a
> snippet of your config, especially the service part?
Here it goes. The manual states that you can have two slim services on
different ttys. Am I misinterpreting something? Thank you!
--8<---cut here---start->8---
(services (cons* (set-xorg-configuration (xorg-configuration
(modules (list xf86-input-libinput
xf86-input-evdev
xf86-input-wacom))
(keyboard-layout keyboard-layout)
(server-arguments
;; disable screen-saver timeout
(append (list "-s" "0")
%default-xorg-server-arguments))
(extra-config (list xorg-touchpad
xorg-monitor)))
slim-service-type)
(service slim-service-type (slim-configuration (display ":0")
(vt "vt7")))
;; Doesn't work to add a 2nd service of the same type,
;; contrary to what the docs say
;; (service slim-service-type (slim-configuration (display
":0")
;;(vt
"vt8")))
(modify-services %desktop-services
(guix-service-type
config => (guix-configuration
(inherit config)
(substitute-urls
(append (list
"https://substitutes.nonguix.org;)
%default-substitute-urls))
(authorized-keys
(append (list (plain-file "non-guix.pub"
nonguix-key))
%default-authorized-guix-keys
(delete gdm-service-type)
(delete (screen-locker-service xlockmore "xlock")
--8<---cut here---end--->8---
--
André A. Gomes
"You cannot even find the ruins..."
bug#55459: Emacs 28.1 and its manual
Hi Guix, I'm running emacs 28.1 but it seems that the manual that I get when I run C-h r is that of emacs 27. I checked /gnu/store/hash-emacs-28.1/share/info and everything looks good, so I assume that for some reason the info program is not getting the most up-to-date manual. Any ideas? -- André A. Gomes "You cannot even find the ruins..."
bug#55435: emacs-libgit fails to build
Hi Guix,
The tests for emacs-libgit fail. I'm reporting it, as I have no idea
how to fix it.
--8<---cut here---start->8---
starting phase `check'
Running tests...
/gnu/store/zga679c4nldah9l8dhd5a4hdy820hcyf-cmake-minimal-3.21.4/bin/ctest
--force-new-ctest-process
Test project /tmp/guix-build-emacs-libgit-20200515-1.0ef8b13.drv-0/build
Start 1: libegit2_annotated-commit
1/29 Test #1: libegit2_annotated-commit Passed0.30 sec
Start 2: libegit2_blame
2/29 Test #2: libegit2_blame ... Passed0.27 sec
Start 3: libegit2_blob
3/29 Test #3: libegit2_blob ***Failed0.29 sec
Running 4 tests (2022-05-15 21:26:04+, selector ‘t’)
Test blob-binary backtrace:
signal(wrong-type-argument (utf-8-string-p "\177ELF\2\1\1\0\0\0\0\0\
apply(signal (wrong-type-argument (utf-8-string-p "\177ELF\2\1\1\0\0
(setq value-42 (apply fn-40 args-41))
(unwind-protect (setq value-42 (apply fn-40 args-41)) (setq form-des
(if (unwind-protect (setq value-42 (apply fn-40 args-41)) (setq form
(let (form-description-44) (if (unwind-protect (setq value-42 (apply
(let ((value-42 'ert-form-evaluation-aborted-43)) (let (form-descrip
(let* ((fn-40 #'string=) (args-41 (condition-case err (let ((signal-
(let* ((repo (libgit-repository-open path)) (blob (libgit-revparse-s
(let ((default-directory path)) (init) (commit-change "filename" str
(progn (make-directory path 'parents) (let ((default-directory path)
(unwind-protect (progn (make-directory path 'parents) (let ((default
(let ((path "/tmp/guix-build-emacs-libgit-20200515-1.0ef8b13.dr...")
(let* ((str (unibyte-string 127 69 76 70 2 1 1 0 0 0 0 0 0 0 0 0 3 0
(let ((lexical-binding nil)) (let* ((str (unibyte-string 127 69 76 7
(lambda nil (let ((lexical-binding nil)) (let* ((str (unibyte-string
ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
ert-run-test(#s(ert-test :name blob-binary :documentation nil :body
ert-run-or-rerun-test(#s(ert--stats :selector t :tests [#s(ert-test
ert-run-tests(t #f(compiled-function (event-type event-args) #
ert-run-tests-batch(nil)
ert-run-tests-batch-and-exit()
command-line-1(("-L" "/tmp/guix-build-emacs-libgit-20200515-1.0ef8b1
command-line()
normal-top-level()
Test blob-binary condition:
(wrong-type-argument utf-8-string-p
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260\7\0\0\0\0\0\0@\0\0\0\0\0\0\0\270\33\0\0\0\0\0\0\0\0\0\0@\08\0\11\0@\0\35\0\34\0\6\0\0\0\5\0\0\0@\0\0\0\0\0\0\0")
FAILED 1/4 blob-binary (0.019616 sec)
passed 2/4 blob-create-fromdisk (0.011500 sec)
passed 3/4 blob-create-fromstring (0.009724 sec)
passed 4/4 blob-text (0.019196 sec)
Ran 4 tests, 3 results as expected, 1 unexpected (2022-05-15 21:26:05+,
0.190591 sec)
1 unexpected results:
FAILED blob-binary
--8<---cut here---end--->8---
--
André A. Gomes
"You cannot even find the ruins..."
bug#55391: Multiple slim services
Hi Guix, The manual (see (info "(guix) X Window")) mentions that it's possible to add two slim services but it seems not to work. When I tried to reconfigure the system it gives the following error: --8<---cut here---start->8--- guix system: error: more than one target service of type 'slim' --8<---cut here---end--->8--- Thanks. -- André A. Gomes "You cannot even find the ruins..."
bug#53588: Missing keys for ISO image
Leo Famulari writes: > On Thu, Jan 27, 2022 at 08:18:06PM +0300, André A. Gomes wrote: >> $ gpg --verify guix-system-install-1.3.0.x86_64-linux.iso.sig >> gpg: no signed data >> gpg: can't hash datafile: No data > > This means that you only downloaded the signature file, but not the ISO > image. Or at least, it's not where GPG expects to find it. Yes, I had the image and the signature is different folders. Silly me. Thanks. Closing (hopefully?). -- André A. Gomes "Free Thought, Free World"
bug#53588: Missing keys for ISO image
Hi Guix, I followed the instructions found at info node (info "(guix) USB Stick and DVD Installation") and it failed with the following error: --8<---cut here---start->8--- $ wget https://sv.gnu.org/people/viewgpg.php?user_id=127547 -qO - | gpg --import - gpg: key 1260E46482E63562: 2 signatures not checked due to missing keys gpg: key 1260E46482E63562: "Maxim Cournoyer " not changed gpg: Total number processed: 1 gpg: unchanged: 1 $ gpg --verify guix-system-install-1.3.0.x86_64-linux.iso.sig gpg: no signed data gpg: can't hash datafile: No data --8<---cut here---end--->8--- -- André A. Gomes "Free Thought, Free World"
bug#52719: Linux modules build fails
Hi Guix,
I issued guix system reconfigure and the linux modules failed to build.
Here's the backtrace:
--8<---cut here---start->8---
Backtrace:
17 (primitive-load "/gnu/store/bvjcb7jbwlky0czin8p66949mil?")
In ice-9/eval.scm:
619:8 16 (_ #f)
626:19 15 (_ #)
293:34 14 (_ #(# #))
In srfi/srfi-1.scm:
586:29 13 (map1 _)
586:29 12 (map1 _)
586:29 11 (map1 _)
586:29 10 (map1 _)
586:29 9 (map1 _)
586:29 8 (map1 _)
586:29 7 (map1 _)
586:29 6 (map1 _)
586:29 5 (map1 _)
586:29 4 (map1 _)
586:29 3 (map1 _)
586:29 2 (map1 _)
586:17 1 (map1 ("simplefb" "pata_acpi" "pata_atiixp" "isci" "?" ?))
In gnu/build/linux-modules.scm:
257:5 0 (_)
gnu/build/linux-modules.scm:257:5: kernel module not found "simplefb"
"/gnu/store/1ai7mxw5ad58ic9slxsjzsxaryi5wksp-linux-libre-5.10.87/lib/modules"
--8<-------cut here---end--->8---
Any ideas? Thank you.
--
André A. Gomes
"Free Thought, Free World"
bug#52650: Guix pull fails building package cache
Leo Famulari writes: > On Sat, Dec 18, 2021 at 11:32:46PM +0000, André A. Gomes wrote: >> I got the following error after issuing guix pull. >> >> --8<---cut here---start->8--- >> building package cache... >> /builder for >> `/gnu/store/6z0pny4mqnhrakqxs1yca5lnxjd1xszr-guix-package-cache.drv' >> failed to produce output path >> `/gnu/store/9spwrk8l40kpi110q47ckay0znmjzbdb-guix-package-cache' >> build of /gnu/store/6z0pny4mqnhrakqxs1yca5lnxjd1xszr-guix-package-cache.drv >> failed >> --8<---cut here---end--->8--- >> >> And the log says: >> >> --8<---cut here---start->8--- >> (repl-version 0 1 1) >> Generating package cache for >> '/gnu/store/c68ygnsa87mqzfnrnkp798qi3jdsixh0-profile'... >> (exception unbound-variable (value #f) (value "Unbound variable: ~S") (value >> (lttng-ust)) (value #f)) >> --8<---cut here---end--->8--- > > Are you using some 3rd-party channels that might need to be adjusted? Oh, right! How can I close this bug report? Thank you. -- André A. Gomes "Free Thought, Free World"
bug#52650: Guix pull fails building package cache
Hi, I got the following error after issuing guix pull. --8<---cut here---start->8--- building package cache... /builder for `/gnu/store/6z0pny4mqnhrakqxs1yca5lnxjd1xszr-guix-package-cache.drv' failed to produce output path `/gnu/store/9spwrk8l40kpi110q47ckay0znmjzbdb-guix-package-cache' build of /gnu/store/6z0pny4mqnhrakqxs1yca5lnxjd1xszr-guix-package-cache.drv failed --8<---cut here---end--->8--- And the log says: --8<---cut here---start->8--- (repl-version 0 1 1) Generating package cache for '/gnu/store/c68ygnsa87mqzfnrnkp798qi3jdsixh0-profile'... (exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (lttng-ust)) (value #f)) --8<---cut here---end--->8--- -- André A. Gomes "Free Thought, Free World"
bug#45758: (no subject)
I'm also facing this issue on GUI Emacs. For instance, even when one does (find-file "path/to/any/org/file"). If anyone wants to reproduce: - emacs -Q - Help -> Search Documentation -> Emacs Terminology Fatal error 11: Segmentation fault Backtrace: /home/aadcg/.guix-profile/bin/emacs[0x50fe24] /home/aadcg/.guix-profile/bin/emacs[0x41f89c] /home/aadcg/.guix-profile/bin/emacs[0x50e65e] /home/aadcg/.guix-profile/bin/emacs[0x50e8b8] /home/aadcg/.guix-profile/bin/emacs[0x50e92c] /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libpthread.so.0(+0x13010)[0x7f5e9d86c010] /home/aadcg/.guix-profile/bin/emacs[0x5cfbe8] /home/aadcg/.guix-profile/bin/emacs[0x58282d] /home/aadcg/.guix-profile/bin/emacs[0x582e09] /home/aadcg/.guix-profile/bin/emacs[0x4c4a67] /home/aadcg/.guix-profile/bin/emacs[0x4c58a0] /home/aadcg/.guix-profile/bin/emacs[0x4c7bc0] /home/aadcg/.guix-profile/bin/emacs[0x438cac] /home/aadcg/.guix-profile/bin/emacs[0x44f0ae] /home/aadcg/.guix-profile/bin/emacs[0x4498a8] /home/aadcg/.guix-profile/bin/emacs[0x450b2d] /home/aadcg/.guix-profile/bin/emacs[0x44f215] /home/aadcg/.guix-profile/bin/emacs[0x456d38] /home/aadcg/.guix-profile/bin/emacs[0x45c575] /home/aadcg/.guix-profile/bin/emacs[0x46e30a] /home/aadcg/.guix-profile/bin/emacs[0x47322b] /home/aadcg/.guix-profile/bin/emacs[0x56a726] /home/aadcg/.guix-profile/bin/emacs[0x43fe8c] /home/aadcg/.guix-profile/bin/emacs[0x460008] /home/aadcg/.guix-profile/bin/emacs[0x5019cb] /home/aadcg/.guix-profile/bin/emacs[0x5040ed] /home/aadcg/.guix-profile/bin/emacs[0x50571e] /home/aadcg/.guix-profile/bin/emacs[0x56a68e] /home/aadcg/.guix-profile/bin/emacs[0x4f76cc] /home/aadcg/.guix-profile/bin/emacs[0x56a5fd] /home/aadcg/.guix-profile/bin/emacs[0x4f7674] /home/aadcg/.guix-profile/bin/emacs[0x4fc596] /home/aadcg/.guix-profile/bin/emacs[0x4fc8a4] /home/aadcg/.guix-profile/bin/emacs[0x421725] /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6(__libc_start_main+0xed)[0x7f5e9d5e9a6d] /home/aadcg/.guix-profile/bin/emacs[0x4222ca] Segmentation fault I assume that reverting back to an older glibc version should fix this issue... -- André Alexandre Gomes "Free Thought, Free World"
bug#45758: (no subject)
Please ignore my previous email. I had an issue with Emacs but I got it fixed with the help of Ludovic on IRC. All I needed was to run "fc-cache -rv". I'm sorry that I got confused about a segmentation fault error triggered by emacs-guix, and not emacs. -- André Alexandre Gomes "Free Thought, Free World"
bug#37935: (no subject)
Olá Pablo Ferreira, Provavelmente falhou porque houve um problema na sua ligação à internet. -- André Alexandre Gomes "Free Thought, Free World"
