bug#65178: Shepherd stops responding during "guix system reconfigure"
On Fri Dec 15, 2023 at 8:47 PM CET, Attila Lendvai wrote: > i think i have found the root cause of this, as documented here: > https://issues.guix.gnu.org/67839 > > that issue contains patches for shepherd to reproduce it in its test suite. Thank you very much for this, Attila! Are the patch in 67839 and/or your branch "attila" linked from there in a state that I could test them locally? Would it be valuable to you if I ran a patched Shepherd and sent logs and/or backtraces as I encountered them?
bug#65178: Shepherd stops responding during "guix system reconfigure"
After a bit of searching, it looks like 67538, 67230 and 65178 may be the same
issue.
Attila Lendvai wrote:
> > > my suspicion is that it's due to some error coming from a start
> > > GEXP that somehow derails shepherd's event loop.
> >
> > iirc I once managed to get a debugger out when it happened and it's
> > stuck waiting in one of the epoll/select/alike calls,
>
> ...or one of the start/stop GEXP's calls something that (sometimes?) blocks
> indefinitely (which violates the API of shepherd).
Same symptoms here again.
For context: this time I was trying to deploy some OCI/Docker containers using
Guix' `oci-container-service-type', specifically a Shepherd service called
"conduit". My code is here:
https://cgit.twilken.net/dotfiles/log/?h=matrix-containers
(Specifically, commits bf94f7872a1df293bd904bbd2c1ef7229f4f98a8 and
c87dcdae79c6266ac3dac70af08fbef5eb21629b.)
This is with Guix commit 1b2505217cf222d98cc960b8510660976a01cfa1.
I first ran "guix system reconfigure -L . tw/system/lud.scm" with commit
bf94f7872a1df293bd904bbd2c1ef7229f4f98a8, which had a bug (an env var was
wrong, so the container failed to start). This worked as expected in that
Shepherd tried to start the service, which failed, so Shepherd disabled it.
Then, I fixed the env var and re-ran "guix system reconfigure -L .
tw/system/lud.scm" with commit c87dcdae79c6266ac3dac70af08fbef5eb21629b.
Shepherd loaded the new "conduit" service fine, as far as I can tell, but
didn't restart it because it was still disabled.
I then enabled and started the service manually. Enabling worked fine, but on
start, I got no terminal output from Shepherd, and it hung.
I still had an error in my setup (directory permissions were wrong), and I got
a message in /var/log/messages to that effect:
--8<---cut here---start->8---
Dec 14 21:33:50 localhost shepherd[1]: Service conduit is currently disabled.
Dec 14 21:34:04 localhost shepherd[1]: Enabled service conduit.
Dec 14 21:34:07 localhost shepherd[1]: Starting service user-homes...
Dec 14 21:34:07 localhost shepherd[1]: Service user-homes has been started.
Dec 14 21:34:07 localhost shepherd[1]: Service user-homes started.
Dec 14 21:34:07 localhost shepherd[1]: Service user-homes running with value
#t.
Dec 14 21:34:07 localhost shepherd[1]: Starting service conduit...
Dec 14 21:34:07 localhost shepherd[1]: Service conduit has been started.
Dec 14 21:34:07 localhost shepherd[1]: Service conduit started.
Dec 14 21:34:07 localhost shepherd[1]: Service conduit running with value
13226.
Dec 14 21:34:07 localhost shepherd[1]: [docker] conduit: [...] "IO error: While
open a file for appending: /var/lib/matrix-conduit/LOG: Permission denied"
--8<---cut here---end--->8---
...showing that Shepherd had at least tried to start the new container. The
container is not running, though (due to the error shown above), and nothing
with PID 13226 is running.
The "herd start conduit" command did not return, and ^C-ing it did not help.
Afterwards, every "herd" command also hung without any output.
Here are the last four lines of the output of "sudo strace -s1000 herd status"
on such a hung machine:
--8<---cut here---start->8---
connect(10, {sa_family=AF_UNIX, sun_path="/var/run/shepherd/socket"}, 26) = 0
getcwd("/home/timo", 100) = 11
write(10, "(shepherd-command (version 0) (action status) (service root)
(arguments ()) (directory \"/home/timo\"))", 101) = 101
read(10,
--8<---cut here---end--->8---
The "read(10, " call never completes.
At least in this case, Shepherd still seems to be processing inbound inet
connections, so I can open new SSH connections to the machine.
Attaching to PID 1 with strace shows it is stuck in "epoll_wait(13, "
(unsurprisingly, fd 13 points to "anon_inode:[eventpoll]"). Here's a backtrace
of all threads in "gdb -p 1":
--8<---cut here---start->8---
(gdb) info threads
Id Target Id Frame
* 1Thread 0x7f786544c380 (LWP 1) "shepherd" 0x7f7865552626 in
epoll_wait ()
from /gnu/store/ln6hxqjvz6m9gdd9s97pivlqck7hzs99-glibc-2.35/lib/libc.so.6
2Thread 0x7f7864e16640 (LWP 186) "GC-marker-0" 0x7f78654cf16a in
__futex_abstimed_wait_common ()
from /gnu/store/ln6hxqjvz6m9gdd9s97pivlqck7hzs99-glibc-2.35/lib/libc.so.6
3Thread 0x7f7864615640 (LWP 187) "GC-marker-1" 0x7f78654cf16a in
__futex_abstimed_wait_common ()
from /gnu/store/ln6hxqjvz6m9gdd9s97pivlqck7hzs99-glibc-2.35/lib/libc.so.6
4Thread 0x7f7863e14640 (LWP 188) "GC-marker-2" 0x7f78654cf16a in
__futex_abstimed_wait_common ()
from /gnu/store/ln6hxqjvz6m9gdd9s97pivlqck7hzs99-glibc-2.35/lib/libc.so.6
5Thread 0x7f78634c6640 (LWP 190) "shepherd"0x7f786554300c in read
()
from /gnu/store/ln6hxqjvz6m9gdd9s97pivlqck7hzs99-glibc-2.35/lib/li
bug#67538: Shepherd stops responding during "guix system reconfigure"
I run Guix System on a remote server, and I've just had Shepherd hang itself
completely during a "guix system reconfigure" -- see the terminal log below.
This is the system Shepherd, i.e. PID 1, so it hanging is obviously not good.
I was debugging some nginx/certbot-related issues, which is the reason for the
many invocations of "guix system reconfigure/roll-back/switch-generation".
I have since force-restarted the machine through /proc/sysrq-trigger. If some
information is missing, it may have to wait until this happens to me again,
sorry!
--8<---cut here---start->8---
$ cd src/tw-channel
$ sudo guix system reconfigure -L . tw/system/X.scm
$ sudo guix system roll-back # 76 -> 75
$ sudo guix system roll-back # 75 -> 74
$ sudo guix system roll-back # 74 -> 73
$ sudo guix system switch-generation 76
$ edit tw/system/X.scm
$ sudo guix system reconfigure -L . tw/system/X.scm --allow-downgrades
guix system: warning: moving channel 'tw' from
6f4319548e425318c057fce48a3b39ceee4dd2ee to unrelated commit
8449867c353192d0c8313d67b3a02549f941ec56
substitute: updating substitutes from 'https://[...]'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
The following derivations will be built:
/gnu/store/ygrlqslg9f5jwv50vjya2wbkzcxi260n-system.drv
/gnu/store/0lvgfm2k4bgs5m338fq5dh7j5n7bhbm5-activate.scm.drv
/gnu/store/gshibgm70parbj4x6y1x42qvq7n8x7c9-activate-service.scm.drv
/gnu/store/z228g6557hg6nmmg1x9i2yp60q6c43qx-nginx.conf.drv
/gnu/store/5s28r9s2mawd423q2azi4cdf203fi4f4-provenance.drv
/gnu/store/jziijs3yg8q78fyn853pdzybpp73d5rd-boot.drv
/gnu/store/58da936wr8zf9501x3m39pqbi7n866b2-shepherd.conf.drv
/gnu/store/fp8cxrqhp58wwsbi75k3369a1yx8ldxy-shepherd-nginx.go.drv
/gnu/store/fyday4l5if26p6ghhra331iyj48s7f0p-shepherd-nginx.scm.drv
/gnu/store/ri2j9rv5d19x98ig1mc7yc3mpiknv88n-grub.cfg.drv
building /gnu/store/5s28r9s2mawd423q2azi4cdf203fi4f4-provenance.drv...
building /gnu/store/z228g6557hg6nmmg1x9i2yp60q6c43qx-nginx.conf.drv...
building /gnu/store/gshibgm70parbj4x6y1x42qvq7n8x7c9-activate-service.scm.drv...
building /gnu/store/fyday4l5if26p6ghhra331iyj48s7f0p-shepherd-nginx.scm.drv...
building /gnu/store/0lvgfm2k4bgs5m338fq5dh7j5n7bhbm5-activate.scm.drv...
building /gnu/store/fp8cxrqhp58wwsbi75k3369a1yx8ldxy-shepherd-nginx.go.drv...
building /gnu/store/58da936wr8zf9501x3m39pqbi7n866b2-shepherd.conf.drv...
building /gnu/store/jziijs3yg8q78fyn853pdzybpp73d5rd-boot.drv...
building /gnu/store/ygrlqslg9f5jwv50vjya2wbkzcxi260n-system.drv...
building /gnu/store/ri2j9rv5d19x98ig1mc7yc3mpiknv88n-grub.cfg.drv...
/gnu/store/6r0j6h4938hz5mddp61b61fw632dndzz-system
/gnu/store/253irqhvid0hkafig7ws4i81zmdsls37-grub.cfg
activating system...
The following derivation will be built:
/gnu/store/wdpjdsxxkb2cyp2y9ffqwhkpf7ajb55k-switch-to-system.scm.drv
building /gnu/store/wdpjdsxxkb2cyp2y9ffqwhkpf7ajb55k-switch-to-system.scm.drv...
making '/gnu/store/6r0j6h4938hz5mddp61b61fw632dndzz-system' the current
system...
setting up setuid programs in '/run/setuid-programs'...
populating /etc from /gnu/store/9yypp4bzsfprdq4vwjcj3f9jcj5dldk3-etc...
`/gnu/store/vxwqfm0fb8nj9flz272iwx8nwa82dsx4-openssh-authorized-keys/[x]' ->
`/etc/ssh/authorized_keys.d/[x]'
`/gnu/store/vxwqfm0fb8nj9flz272iwx8nwa82dsx4-openssh-authorized-keys/[y]' ->
`/etc/ssh/authorized_keys.d/[y]'
/var/lib/certbot/renew-certificates may need to be run
creating nginx log directory '/var/log/nginx'
creating nginx run directory '/var/run/nginx'
creating nginx temp directories
'/var/run/nginx/{client_body,proxy,fastcgi,uwsgi,scgi}_temp'
nginx: the configuration file
/gnu/store/hkldki7rxg82i9nb3flsq6x58h81p2qr-nginx.conf syntax is ok
nginx: configuration file
/gnu/store/hkldki7rxg82i9nb3flsq6x58h81p2qr-nginx.conf test is successful
The following derivation will be built:
/gnu/store/dnz992gzxhpaq7xjcakdi53rdannsimf-install-bootloader.scm.drv
building
/gnu/store/dnz992gzxhpaq7xjcakdi53rdannsimf-install-bootloader.scm.drv...
guix system: bootloader successfully installed on '(/boot/efi)'
The following derivation will be built:
/gnu/store/q76v0yrh6vnbjiq2fw236lvn5mc2nl32-upgrade-shepherd-services.scm.drv
building
/gnu/store/q76v0yrh6vnbjiq2fw236lvn5mc2nl32-upgrade-shepherd-services.scm.drv...
shepherd: Removing service 'fcgiwrap'...
shepherd: Done.
[ at this point, the process hangs ]
--8<---cut here---end--->8---
The mentioned derivation
/gnu/store/q76v0yrh6vnbjiq2fw236lvn5mc2nl32-upgrade-shepherd-services.scm.drv
builds the following upgrade-shepherd-services.scm:
--8<---cut here---start->8---
;; /gnu/store/qi2g4figwfn44nrlsaxgjn4p9sps6qv8-upgrade-shepherd-services.scm
[ %load-path mangling omitted ]
(begin
(use-modules (gnu services herd) (srfi srfi-1))
(parameterize
((shepherd-message-port (%make-void-port "w")))
bug#63194: Fixed: OpenMoji font is drawn invisibly
This issue does not occur any more for me. Closing.
bug#63001: bug#63631: [PATCH] import: go: Handle subpackage versioning correctly.
Hi Ludo', (hi everyone,) On Wed Jun 14, 2023 at 11:09 PM CEST, Ludovic Courtès wrote: > Timo Wilken skribis: > > Here's a patch that fixes the reported issue (bug#54097) for me. I've only > > tested this on the github.com/googleapis/google-cloud-go/compute package so > > far, though it seems to work there. Perhaps others have more testcases? > > > > I don't know enough about Go tooling to use it, so I've just patched the > > Guile > > logic of the importer. (I don't write Go, I just want to package stuff > > written > > in it.) In terms of performance, at least the repo contents are apparently > > cached by the first `git-checkout-hash' call, even if it fails, so the > > second > > call doesn't have to redownload them. I've been testing my patch further this weekend, and I have a couple more patches in the pipeline; I suppose I ought to clean those up and submit them. In particular, I've got fixes for the following queued up locally: 1. Finding the `module-path-subdir' needs another case for e.g. cloud.google.com/go/*. 2. My patch sometimes generates an unnecessary `go-version->git-ref' call. 3. Go versions need to be parsed from go.mod, since some packages require a newer Go compiler than our default. This I've got a patch for, but this Go version also ought to propagate up the dependency tree. I haven't found an easy way to do that, since the importer seems to generate top-level packages first, before descending the dep tree... 4. `fetch-module-meta-data' ought to ignore 4xx HTTP errors to follow the spec; gonum.org/v1/gonum specifically depends on this behaviour. I've been trying to recursively import github.com/matrix-org/dendrite, which has a particularly large and hairy dependency tree. While I can now import it without crashes, I can't build it from the imported package definitions yet -- mainly because of lots of dependency cycles in the generated packages, but there may be more issues hidden beneath that. Still, I can recommend it as a test of everyone's importer patches, since it'll find a lot of edge cases in importing alone! > What you propose looks similar to part of the work Simon Tournier > submitted at <https://issues.guix.gnu.org/63647>. It seems lots of people have been working on the same problem -- in addition to Simon's patches, I found a patch submitted by Elbek (issues 64035 & 64036; Cc'd). I also forgot about the issue I submitted months ago (63001)... > What would you suggest? Simon? Here's a brief comparison between Simon's patches and mine -- Simon's seem to contain fixes for a couple more things than mine currently does: 1. Simon sorts available versions in an error message; this can presumably be merged independently since it doesn't conflict with other patches. 2. Simon always prepends a "SUBDIR/" prefix to the tag if found, whereas I try to find the plain "vX" tag first, then fall back to "SUBDIR/vX". Judging by https://go.dev/ref/mod#vcs-version, Simon's approach seems more correct. I'll change my implementation to match and try it out. 3. For detecting the `module-path-subdirectory' in Simon's patches: that's the same approach I used initially, but I found I have to try `(substring module-path (string-length import-prefix))' first (to handle e.g. cloud.google.com/go/*). This is one of the things I haven't submitted yet... > Thanks for the patch, Timo! Thanks for your work in sorting through all of this, Ludo'! Cheers, Timo signature.asc Description: PGP signature
bug#54097: [PATCH] import: go: Handle subpackage versioning correctly.
Hi wolf, On Sun May 21, 2023 at 11:54 PM CEST, wolf wrote: > Please give the github.com/Azure/go-autorest/tracing@v0.6.0 a go. My code > failed on it, and (assuming I applied the patch correctly) your does as well. > Here are reproduction steps to make it easier for you (please tell me if I did > something wrong): I don't think you did anything wrong there. That's an issue I've run into in the past as well, though it seems to be a bug in the Go build system, not the importer (and in my patch I only touch the importer). > I will not pretend to have a full grasp on how (guix build-system go) works, > however my debugging lead me to the observation that it tries to unpack two > dependencies into one file system tree overlayed on top of each other. I > think > the current way (GO111MODULE=off) of building of golang packages does not play > very well with well, go modules. Fair enough! I don't know much about Go -- I don't write software in it, I just want to package some stuff written in it; in my case, that's Matrix-related programs. > Either the build system needs to be smarter about unpacking dependencies (and > doing it in a correct order), or we should start using go modules for the > builds > (it can still be down offline, just the dependencies are in different paths). > The second approach is what I wanted to explore, but did not get to it yet > (and > likely will not for a month or two). Your second approach sounds sensible! If I can find the time and motivation to dig in to this, I might have a go as well... But if you get anything working, that would be much appreciated! :) Cheers, Timo
bug#54097: [PATCH] import: go: Handle subpackage versioning correctly.
Some Go source repositories (notably the Google Cloud SDK) contain multiple
submodules and use a `refs/tags//' tagging scheme.
Fixes <https://bugs.gnu.org/54097>.
* guix/import/go.scm (vcs->origin): Accept a module-path-suffix.
(go-module->guix-package): Use the new parameter.
---
Here's a patch that fixes the reported issue (bug#54097) for me. I've only
tested this on the github.com/googleapis/google-cloud-go/compute package so
far, though it seems to work there. Perhaps others have more testcases?
I don't know enough about Go tooling to use it, so I've just patched the Guile
logic of the importer. (I don't write Go, I just want to package stuff written
in it.) In terms of performance, at least the repo contents are apparently
cached by the first `git-checkout-hash' call, even if it fails, so the second
call doesn't have to redownload them.
guix/import/go.scm | 56 +++---
1 file changed, 43 insertions(+), 13 deletions(-)
diff --git a/guix/import/go.scm b/guix/import/go.scm
index 0357e6a1eb..652ac58b6f 100644
--- a/guix/import/go.scm
+++ b/guix/import/go.scm
@@ -7,6 +7,7 @@
;;; Copyright © 2021 Xinglu Chen
;;; Copyright © 2021 Sarah Morgensen
;;; Copyright © 2021 Simon Tournier
+;;; Copyright © 2023 Timo Wilken
;;;
;;; This file is part of GNU Guix.
;;;
@@ -89,6 +90,7 @@ (define-module (guix import go)
;;; TODO list
;;; - get correct hash in vcs->origin for Mercurial and Subversion
+;;; - handle subdir/vX.Y versioning in vcs->origin for Mercurial and Subversion
;;; Code:
@@ -513,29 +515,54 @@ (define* (git-checkout-hash url reference algorithm)
`(tag-or-commit . ,reference)
(file-hash* checkout #:algorithm algorithm #:recursive? #true)))
-(define (vcs->origin vcs-type vcs-repo-url version)
+(define (vcs->origin vcs-type vcs-repo-url module-path-suffix version)
"Generate the `origin' block of a package depending on what type of source
control system is being used."
(case vcs-type
((git)
- (let ((plain-version? (string=? version (go-version->git-ref version)))
- (v-prefixed?(string-prefix? "v" version)))
+ (let ((v-prefixed? (string-prefix? "v" version))
+ (path-prefixed? #f)
+ (trimmed-path-suffix (string-trim-both module-path-suffix #\/))
+ (checkout-hash (false-if-git-not-found
+ (git-checkout-hash
+vcs-repo-url
+(go-version->git-ref version)
+(hash-algorithm sha256)
+ ;; If `checkout-hash' is false, that must mean that a tag named after
+ ;; the version doesn't exist. Some repos that contain submodules use a
+ ;; / tagging scheme instead, so try that.
+ (unless checkout-hash
+ (when (string=? "" trimmed-path-suffix)
+ ;; If this isn't a submodule, / tagging makes
no sense.
+ ;; Tell the user we couldn't find the original version.
+ (raise
+(formatted-message (G_ "could not find git reference '~a' in
repository '~a'")
+ (go-version->git-ref version) vcs-repo-url)))
+ (set! path-prefixed? #t)
+ (set! checkout-hash (git-checkout-hash
+ vcs-repo-url
+ (go-version->git-ref
+ (string-append trimmed-path-suffix "/" version))
+ (hash-algorithm sha256
`(origin
(method git-fetch)
(uri (git-reference
(url ,vcs-repo-url)
-;; This is done because the version field of the package,
-;; which the generated quoted expression refers to, has been
-;; stripped of any 'v' prefixed.
-(commit ,(if (and plain-version? v-prefixed?)
- '(string-append "v" version)
- '(go-version->git-ref version)
+;; The 'v' is prepended again because the version field of
+;; the package, which the generated quoted expression refers
+;; to, has been stripped of any 'v' prefixed.
+(commit (go-version->git-ref
+ ,(cond
+ (path-prefixed?
+`(string-append
+ ,trimmed-path-suffix "/"
+ ,@(if v-prefixed? '("v" version) '(version
+ (v-prefixed? '(string-append "v" version))
+ (else 'version))
(file-name
bug#63024: Crash during `guix import pypi -r'
The `guix import pypi -r ...' command frequently crashes for me. When
it does, it always crashes on the third download, the one for the
first dependency's source distribution, like so:
--8<---cut here---start->8---
$ guix import pypi -r calcure
Starting download of /tmp/guix-file.7aaMby
>From
>https://files.pythonhosted.org/packages/61/e3/c960430852d4322d42e02421690958f47fa2b42aaf4f3befb25c1c8baf21/calcure-2.8.6.tar.gz...
…8.6.tar.gz 42KiB 2.1MiB/s 00:00 [##] 100.0%
Starting download of /tmp/guix-file.mPnbsd
>From
>https://files.pythonhosted.org/packages/b5/a8/8ba240c952a13b3b2bee64356dc1a1515c496100dc4c9edb6a6648927864/calcure-2.8.6-py3-none-any.whl...
…y3-none-any.whl 49KiB 1.9MiB/s 00:00 [##] 100.0%
Starting download of /tmp/guix-file.XzIPz0
>From
>https://files.pythonhosted.org/packages/24/91/77edc7626400922d44019753c39e0fd911176ce3f77c3f85ac832d5d70b7/holidays-0.23.tar.gz...
In procedure connect*: Connection timed out
Starting download of /tmp/guix-file.XzIPz0
>From
>https://web.archive.org/web/20230422212928/https://files.pythonhosted.org/packages/24/91/77edc7626400922d44019753c39e0fd911176ce3f77c3f85ac832d5d70b7/holidays-0.23.tar.gz...
In procedure connect*: Connection timed out
Trying to use Disarchive to assemble /tmp/guix-file.XzIPz0...
could not find its Disarchive specification
failed to download "/tmp/guix-file.XzIPz0" from
"https://files.pythonhosted.org/packages/24/91/77edc7626400922d44019753c39e0fd911176ce3f77c3f85ac832d5d70b7/holidays-0.23.tar.gz";
Backtrace:
10 (primitive-load "/home/timo/.config/guix/current/bin/gu…")
In guix/ui.scm:
2300:7 9 (run-guix . _)
2263:10 8 (run-guix-command _ . _)
In guix/scripts/import.scm:
89:11 7 (guix-import . _)
In ice-9/boot-9.scm:
1752:10 6 (with-exception-handler _ _ #:unwind? _ # _)
In guix/scripts/import/pypi.scm:
97:21 5 (_)
In guix/import/utils.scm:
638:3 4 (recursive-import _ #:repo->guix-package _ #:guix-name . #)
600:31 3 (topological-sort _ # …)
In srfi/srfi-1.scm:
586:17 2 (map1 (("holidays" #f) ("jdatetime" #f) ("ics" #f)))
In guix/import/utils.scm:
630:33 1 (lookup-node "holidays" #f)
In ice-9/boot-9.scm:
1685:16 0 (raise-exception _ #:continuable? _)
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Wrong number of values returned to continuation (expected 2)
--8<---cut here---end--->8---
However, that URL is valid -- running a manual `guix download'
afterwards works fine:
--8<---cut here---start->8---
$ guix download
'https://files.pythonhosted.org/packages/24/91/77edc7626400922d44019753c39e0fd911176ce3f77c3f85ac832d5d70b7/holidays-0.23.tar.gz'
Starting download of /tmp/guix-file.vsuTGB
>From
>https://files.pythonhosted.org/packages/24/91/77edc7626400922d44019753c39e0fd911176ce3f77c3f85ac832d5d70b7/holidays-0.23.tar.gz...
….23.tar.gz 374KiB 2.5MiB/s 00:00 [##] 100.0%
/gnu/store/jk0v685hhwirl16la349c7i5is640181-holidays-0.23.tar.gz
0yxs1lzbqykl25yf1hcrqjb7qqw69f2zgf7991slnkmk98p1bsxw
--8<---cut here---end--->8---
bug#63001: Go importer doesn't know MODULE/vX.Y version tags
Some Golang repositories apparently use a tagging scheme where each submodule in the repo gets its own tags. In this case, the example is cloud.google.com/go and its submodules (hosted at https://github.com/googleapis/google-cloud-go). For example, for the cloud.google.com/go/longrunning submodule at version 0.4.1, the Go importer should look for a tag called "refs/tags/longrunning/v0.4.1" in the Git repository. #+begin_example $ guix import go -r cloud.google.com/go/longrunning Backtrace: 19 (primitive-load "/home/timo/.config/guix/current/bin/gu…") In guix/ui.scm: 2300:7 18 (run-guix . _) 2263:10 17 (run-guix-command _ . _) In guix/scripts/import.scm: 89:11 16 (guix-import . _) In ice-9/boot-9.scm: 1752:10 15 (with-exception-handler _ _ #:unwind? _ # _) In guix/scripts/import/go.scm: 114:22 14 (_) In guix/import/utils.scm: 638:27 13 (recursive-import _ #:repo->guix-package _ #:guix-name . #) 630:33 12 (lookup-node "cloud.google.com/go/longrunning" #f) In guix/memoization.scm: 98:0 11 (mproc "cloud.google.com/go/longrunning" # # …) In unknown file: 10 (_ # …) In guix/import/go.scm: 685:10 9 (_ _ #:version _ #:repo _) In ice-9/exceptions.scm: 406:15 8 (go-module->guix-package* . _) In ice-9/boot-9.scm: 1752:10 7 (with-exception-handler _ _ #:unwind? _ # _) In guix/import/go.scm: 511:19 6 (go-module->guix-package "cloud.google.com/go/longrunn…" …) In guix/git.scm: 291:4 5 (update-cached-checkout _ #:ref _ #:recursive? _ # _ # _ …) 277:19 4 (resolve _) In git/reference.scm: 60:8 3 (_ _ _) In git/bindings.scm: 77:2 2 (raise-git-error _) In ice-9/boot-9.scm: 1685:16 1 (raise-exception _ #:continuable? _) 1683:16 0 (raise-exception _ #:continuable? _) ice-9/boot-9.scm:1683:16: In procedure raise-exception: Git error: reference 'refs/tags/v0.4.1' not found #+end_example The same is true for other modules, e.g. github.com/Azure/azure-sdk-for-go/sdk/internal, where the tag is called "refs/tags/sdk/internal/v1.3.0" instead: #+begin_example $ guix import go -r github.com/Azure/azure-sdk-for-go/sdk/internal Backtrace: 19 (primitive-load "/home/timo/.config/guix/current/bin/gu…") In guix/ui.scm: 2300:7 18 (run-guix . _) 2263:10 17 (run-guix-command _ . _) In guix/scripts/import.scm: 89:11 16 (guix-import . _) In ice-9/boot-9.scm: 1752:10 15 (with-exception-handler _ _ #:unwind? _ # _) In guix/scripts/import/go.scm: 114:22 14 (_) In guix/import/utils.scm: 638:27 13 (recursive-import _ #:repo->guix-package _ #:guix-name . #) 630:33 12 (lookup-node "github.com/Azure/azure-sdk-for-go/sdk/in…" …) In guix/memoization.scm: 98:0 11 (mproc "github.com/Azure/azure-sdk-for-go/sdk/internal" …) In unknown file: 10 (_ # …) In guix/import/go.scm: 685:10 9 (_ _ #:version _ #:repo _) In ice-9/exceptions.scm: 406:15 8 (go-module->guix-package* . _) In ice-9/boot-9.scm: 1752:10 7 (with-exception-handler _ _ #:unwind? _ # _) In guix/import/go.scm: 511:19 6 (go-module->guix-package "github.com/Azure/azure-sdk-f…" …) In guix/git.scm: 291:4 5 (update-cached-checkout _ #:ref _ #:recursive? _ # _ # _ …) 277:19 4 (resolve _) In git/reference.scm: 60:8 3 (_ _ _) In git/bindings.scm: 77:2 2 (raise-git-error _) In ice-9/boot-9.scm: 1685:16 1 (raise-exception _ #:continuable? _) 1683:16 0 (raise-exception _ #:continuable? _) ice-9/boot-9.scm:1683:16: In procedure raise-exception: Git error: reference 'refs/tags/v1.3.0' not found #+end_example
bug#61914: IceCat does not start with en_GB.utf8 locale
I cannot start IceCat with a non-C locale. It opens an almost-blank window, and I cannot open new tabs or navigate to any URL. If I run `LANG=C icecat', then it works fine. I use `guix system' and `guix home', and have IceCat installed in my `guix home' profile. I have my operating-system configured with the following locales: (locale "en_GB.utf8") (locale-definitions (list (locale-definition (name "en_GB.utf8") (source "en_GB")) (locale-definition (name "en_US.utf8") (source "en_US")) (locale-definition (name "fr_FR.utf8") (source "fr_FR" This is the output when running IceCat in my terminal (without explicitly setting LANG, so that it retains its value of "en_GB.utf8"): $ icecat ATTENTION: default value of option mesa_glthread overridden by environment. ATTENTION: default value of option mesa_glthread overridden by environment. ATTENTION: default value of option mesa_glthread overridden by environment. JavaScript error: chrome://pocket/content/SaveToPocket.jsm, line 130: NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIStringBundle.formatStringFromName] JavaScript error: chrome://browser/content/tabbrowser.js, line 7004: NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIStringBundle.GetStringFromName] JavaScript error: chrome://browser/content/tabbrowser-tabs.js, line 64: NS_ERROR_UNEXPECTED: Component returned failure code: 0x8000 (NS_ERROR_UNEXPECTED) [nsIStringBundle.GetStringFromName] JavaScript error: resource:///modules/sessionstore/SessionStore.jsm, line 2458: TypeError: browser is undefined JavaScript error: resource:///modules/UrlbarInput.jsm, line 2641: NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIStringBundle.GetStringFromName] JavaScript error: chrome://browser/content/browser.js, line 8052: TypeError: browser is undefined JavaScript error: resource:///modules/sessionstore/TabStateFlusher.jsm, line 230: TypeError: browser is undefined Missing chrome or resource URL: resource://gre/modules/UpdateListener.jsm Missing chrome or resource URL: resource://gre/modules/UpdateListener.sys.mjs console.error: "Error during quit-application-granted: [Exception... \"File error: Not found\" nsresult: \"0x80520012 (NS_ERROR_FILE_NOT_FOUND)\" location: \"JS frame :: resource:///modules/BrowserGlue.jsm :: _onQuitApplicationGranted/tasks< :: line 1996\" data: no]" $ guix shell glibc -- locale LANG=en_GB.utf8 LC_CTYPE="en_GB.utf8" LC_NUMERIC="en_GB.utf8" LC_TIME="en_GB.utf8" LC_COLLATE="en_GB.utf8" LC_MONETARY="en_GB.utf8" LC_MESSAGES="en_GB.utf8" LC_PAPER="en_GB.utf8" LC_NAME="en_GB.utf8" LC_ADDRESS="en_GB.utf8" LC_TELEPHONE="en_GB.utf8" LC_MEASUREMENT="en_GB.utf8" LC_IDENTIFICATION="en_GB.utf8" LC_ALL= $ guix shell glibc -- locale -a C en_GB.utf8 en_US.utf8 fr_FR.utf8 POSIX $ guix describe Generation 2Mar 02 2023 13:25:29(current) [one non-free channel omitted] guix a7763e0 repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: a7763e067d86908210758aab80d33e4f8b815b1c GUIX_PACKAGE_PATH="/home/twilken/src/guix-decls" $ ls -l "$(which icecat)" lrwxrwxrwx 1 root root 84 Jan 1 1970 /home/twilken/.guix-home/profile/bin/icecat -> /gnu/store/bwcrfgfrri9bpglgb5raih167jaxibkv-icecat-102.8.0-guix0-preview1/bin/icecat
bug#61914: IceCat does not start with en_GB.utf8 locale
Hi Maxim, Thanks for your reply! What finally worked for me was the following: $ sed -i.bak 's|/gnu/store/hhfcn8viysyz2qz9rvvqkj91i5nxzd9s|/gnu/store/bwcrfgfrri9bpglgb5raih167jaxibkv|g' \ ~/.mozilla/icecat/vfc41hol.default/extensions.json \ ~/.mozilla/icecat/vfc41hol.default/addonStartup.json.lz4 After running that, IceCat suddenly worked fine. No directory starting with /gnu/store/hhfcn8viysyz2qz9rvvqkj91i5nxzd9s exists on my system. I guess that means the "guix gc" I did yesterday is to blame! There were lots of entries like the following in my extensions.json: "rootURI":"jar:file:///gnu/store/hhfcn8viysyz2qz9rvvqkj91i5nxzd9s-icecat-102.8.0-guix0-preview1/lib/icecat/browser/extensions/langpack...@icecat.mozilla.org.xpi!/", ...and then when guix gc deleted an old IceCat directory, these files were gone. Is there some way of forcing IceCat not to embed the /gnu/store path in the user's profile at runtime? On Thu Mar 2, 2023 at 3:54 PM CET, Maxim Cournoyer wrote: > Could you try running with a fresh profile? E.g., 'icecat > --ProfileManager', create a new profile, and start it from there? This works, as does using icecat --safe-mode (which presumably avoids loading all extensions and language packs). The new profile has the right /gnu/store paths embedded in extensions.json (i.e. those pointing to the "current" IceCat). I suppose this will blow up as well on the next guix gc... > It should work. I suspect the problem may be caused by > 'intl.locale.requested' being set to something. It needs to be unset > for the system locale to be honored, so if that's the problem with your > current profile, you could try clearing it by visiting "about:config" in > the URL bar. This setting was already cleared. Cheers, Timo
