Re: Packaging Grafana
Katherine Cox-Buday writes: Sorry, I had a bug in my format one-liner which gave versions parenthesis. This should be copy/pastable: --8<---cut here---start->8--- scheme@(guix import go)> (for-each (lambda (p) (format #t "guix import go -r ~a@~a >> grafana.scm~%" (car p) (second p))) $11) guix import go -r google.golang.org/genproto@v0.0.0-20220421151946-72621c1f0bd3 >> grafana.scm guix import go -r google.golang.org/grpc@v1.45.0 >> grafana.scm guix import go -r github.com/grafana/prometheus-alertmanager@v0.24.1-0.20221012142027-823cd9150293 >> grafana.scm guix import go -r github.com/grafana/xorm@v0.8.3-0.20220614223926-2fcda7565af6 >> grafana.scm guix import go -r github.com/hashicorp/go-hclog@v0.16.1 >> grafana.scm guix import go -r github.com/grafana/saml@v0.4.9-0.20220727151557-61cd9c9353fc >> grafana.scm guix import go -r github.com/moby/moby@v0.7.3-0.20190826074503-38ab9da00309 >> grafana.scm guix import go -r github.com/gomodule/redigo@v1.8.9 >> grafana.scm guix import go -r github.com/russellhaering/goxmldsig@v1.1.1 >> grafana.scm guix import go -r github.com/grafana/go-mssqldb@v0.0.0-20210326084033-d0ce3c521036 >> grafana.scm guix import go -r gopkg.in/warnings.v0@v0.1.2 >> grafana.scm guix import go -r golang.org/x/mod@v0.7.0 >> grafana.scm guix import go -r go.opentelemetry.io/proto/otlp@v0.16.0 >> grafana.scm guix import go -r go.opentelemetry.io/otel/exporters/otlp/internal/retry@v1.7.0 >> grafana.scm guix import go -r github.com/yudai/pp@v2.0.1+incompatible >> grafana.scm guix import go -r github.com/xlab/treeprint@v1.1.0 >> grafana.scm guix import go -r github.com/xanzy/ssh-agent@v0.3.0 >> grafana.scm guix import go -r github.com/wk8/go-ordered-map@v1.0.0 >> grafana.scm guix import go -r github.com/valyala/fasttemplate@v1.2.1 >> grafana.scm guix import go -r github.com/pierrec/lz4/v4@v4.1.12 >> grafana.scm guix import go -r github.com/mschoch/smat@v0.2.0 >> grafana.scm guix import go -r github.com/mitchellh/go-wordwrap@v1.0.1 >> grafana.scm guix import go -r github.com/mitchellh/go-homedir@v1.1.0 >> grafana.scm guix import go -r github.com/labstack/gommon@v0.3.1 >> grafana.scm guix import go -r github.com/labstack/echo/v4@v4.9.0 >> grafana.scm guix import go -r github.com/kylelemons/godebug@v1.1.0 >> grafana.scm guix import go -r github.com/klauspost/compress@v1.15.5 >> grafana.scm guix import go -r github.com/kevinburke/ssh_config@v0.0.0-20201106050909-4977a11b4351 >> grafana.scm guix import go -r github.com/jbenet/go-context@v0.0.0-20150711004518-d14ea06fba99 >> grafana.scm guix import go -r github.com/imdario/mergo@v0.3.12 >> grafana.scm guix import go -r github.com/grpc-ecosystem/grpc-gateway/v2@v2.10.3 >> grafana.scm guix import go -r github.com/google/go-github@v17.0.0+incompatible >> grafana.scm guix import go -r github.com/golang-jwt/jwt@v3.2.2+incompatible >> grafana.scm guix import go -r github.com/go-logr/stdr@v1.2.2 >> grafana.scm guix import go -r github.com/go-logr/logr@v1.2.3 >> grafana.scm guix import go -r github.com/go-git/go-billy/v5@v5.3.1 >> grafana.scm guix import go -r github.com/go-git/gcfg@v1.5.0 >> grafana.scm guix import go -r github.com/ghodss/yaml@v1.0.1-0.20190212211648-25d852aebe32 >> grafana.scm guix import go -r github.com/emirpasic/gods@v1.12.0 >> grafana.scm guix import go -r github.com/elazarl/goproxy@v0.0.0-20220115173737-adb46da277ac >> grafana.scm guix import go -r github.com/dgryski/go-metro@v0.0.0-20211217172704-adc40b04c140 >> grafana.scm guix import go -r github.com/coreos/go-semver@v0.3.0 >> grafana.scm guix import go -r github.com/chromedp/cdproto@v0.0.0-20220208224320-6efb837e6bc2 >> grafana.scm guix import go -r github.com/caio/go-tdigest@v3.1.0+incompatible >> grafana.scm guix import go -r github.com/blugelabs/ice@v1.0.0 >> grafana.scm guix import go -r github.com/blevesearch/vellum@v1.0.7 >> grafana.scm guix import go -r github.com/blevesearch/snowballstem@v0.9.0 >> grafana.scm guix import go -r github.com/blevesearch/segment@v0.9.0 >> grafana.scm guix import go -r github.com/blevesearch/mmap-go@v1.0.4 >> grafana.scm guix import go -r github.com/blevesearch/go-porterstemmer@v1.0.3 >> grafana.scm guix import go -r github.com/bits-and-blooms/bitset@v1.2.0 >> grafana.scm guix import go -r github.com/axiomhq/hyperloglog@v0.0.0-20191112132149-a4c4c47bc57f >> grafana.scm guix import go -r github.com/acomagu/bufpipe@v1.0.3 >> grafana.scm guix import go -r github.com/RoaringBitmap/roaring@v0.9.4 >> grafana.scm guix import go -r github.com/ProtonMail/go-crypto@v0.0.0-20210428141323-04723f9f07d7 >> grafana.scm guix import go -r github.com/Micr
Re: Getting tree-sitter grammars in Guix
Demis Balbach writes: > Hello, I was wondering what the "correct" way would be to get grammars > for the tree-sitter library available in Guix when using tree-sitter > with Emacs 29+. > > There is https://github.com/emacs-tree-sitter/tree-sitter-langs, but I > don't think it has been packaged in Guix yet. I started packaging the > grammar for JS/TS: > > (define-public tree-sitter-javascript > (let ((commit "7a29d06274b7cf87d643212a433d970b73969016") > (revision "0") > (version "0.20.0")) > (package > (name "tree-sitter-javascript") > (version (git-version version revision commit)) > (source > (origin >(method git-fetch) >(uri (git-reference > (url "https://github.com/tree-sitter/tree-sitter-javascript;) > (commit commit))) >(sha256 > (base32 "1pk6d9g6a7bzhxmwnvfiycarcgz76wq2rgfqr0xjh7y7swfw5hvw")) >(file-name (git-file-name name version > (build-system gnu-build-system) > (native-inputs > (list gcc)) > (arguments > `(#:tests? > #f > #:phases > (modify-phases > %standard-phases > (delete 'configure) > (delete 'install) > (delete 'build) > (add-after 'unpack 'create-dirs > (lambda _ (mkdir "lib"))) > (add-after 'create-dirs 'compile > (lambda* (#:key inputs outputs #:allow-other-keys) > (let* ((out (assoc-ref outputs "out")) > (gcc (string-append (assoc-ref inputs "gcc") > "/bin"))) > (copy-file "grammar.js" "src/grammar.js") > (with-directory-excursion > (string-append "./src") > (invoke (string-append gcc "/gcc") "-fPIC" "-c" > "-I." "parser.c") > (invoke (string-append gcc "/gcc") "-fPIC" "-c" > "-I." "scanner.c") > (invoke (string-append gcc "/gcc") > "-fPIC" "-shared" "parser.o" "scanner.o" "-o" > "libtree-sitter-javascript.so") > (add-after 'compile 'symlink > (lambda* (#:key inputs outputs #:allow-other-keys) > (let* ((out (assoc-ref outputs "out")) > (lib (string-append out "/lib"))) > (install-file "src/libtree-sitter-javascript.so" > lib))) > (home-page "https://github.com/tree-sitter/tree-sitter-javascript;) > (synopsis "JavaScript and JSX grammar for tree-sitter.") > (description "JavaScript and JSX grammar for tree-sitter.") > (license license:expat > > But I'm not sure if packaging each grammar is the correct way. I > hesitate to continue working on this because there are not other > grammars packaged in Guix (yet). With tree-sitter being built into > Emacs 29+ I expected grammars to be packaged already (hence why I'm > asking if this approach is correct). This seems correct to me, but you might get more informed opinions on guix-de...@gnu.org (CCed), since this is a packaging question. > > Thanks in advance! -- Katherine
Re: question about updating packages
Gottfried writes: > Is this the normal process if one package can't be buld locally? This is what I do because only one or two packages fail to build for me at a time, but I think you can try `guix package -u --keep-going` (I've never used it, so I'm not positive). -- Katherine
Re: Packaging Grafana
phodina via writes:
> Hi Guix,
Hey Petr, thanks for having a go at packaging this! It would be awesome
to have Grafana in Guix!
I was able to troubleshoot this a little. I agree with the sentiment[1][2]
that the Guix importer should just use Go tooling; however, I don't
think it's at fault here.
By default, the importer uses https://proxy.golang.org to fetch a
module's go.mod file. Let's see what that says:
--8<---cut here---start->8---
$ curl
https://proxy.golang.org/github.com/grafana/grafana/@v/v5.4.5+incompatible.mod
module github.com/grafana/grafana
--8<---cut here---end--->8---
Weird.
Also, pkg.go.dev versions seem to disagree with both Git tags and
Grafana's stated latest version, v9.3.2:
--8<---cut here---start->8---
$ git ls-remote --tags g...@github.com:grafana/grafana.git |awk '{print $2}'
|sort |tail -4
refs/tags/v9.3.2
refs/tags/v9.3.2^{}
refs/tags/vtest-new-release-pipeline
refs/tags/vtest-new-release-pipeline^{}
--8<---cut here---end--->8---
Then there's this commit[3], stating:
**Warning:** Do not use `go get` to download Grafana. Recent
versions of Go have added behavior which isn't compatible with
the way the Grafana repository is structured.
OK, so I think even Go's toolchain is having issues with this.
If I start a REPL, we can test out theory:
--8<---cut here---start->8---
$ guix repl
scheme@(guile-user)> ,m (guix import go)
scheme@(guix import go)> (http-fetch*
"https://raw.githubusercontent.com/grafana/grafana/v9.3.2/go.mod;)
$9 = [removed lengthy go.mod output]
scheme@(guix import go)> (parse-go.mod $9)
$10 = [removed lengthy parsed representation]
scheme@(guix import go)> (go.mod-requirements $10)
$11 = (("google.golang.org/genproto" "v0.0.0-20220421151946-72621c1f0bd3")
("google.golang.org/grpc" "v1.45.0") [etc..])
scheme@(guix import go)> (length $11)
$12 = 319
--8<---cut here---end--->8---
That looks plausibly correct.
So to work around Grafana's weirdness, we can just manually import all
of its requirements, recursively. I think you should be able to
cut-paste this and, if there are no more weird packages, you'll be off
to the races :)
--8<---cut here---start->8---
scheme@(guix import go)> (for-each (lambda (p) (format #t "guix import go -r
~a@~a >> grafana.scm~%" (car p) (cdr p))) $11)
guix import go -r
google.golang.org/genproto@(v0.0.0-20220421151946-72621c1f0bd3) >> grafana.scm
guix import go -r google.golang.org/grpc@(v1.45.0) >> grafana.scm
guix import go -r
github.com/grafana/prometheus-alertmanager@(v0.24.1-0.20221012142027-823cd9150293)
>> grafana.scm
guix import go -r
github.com/grafana/xorm@(v0.8.3-0.20220614223926-2fcda7565af6) >> grafana.scm
guix import go -r github.com/hashicorp/go-hclog@(v0.16.1) >> grafana.scm
guix import go -r
github.com/grafana/saml@(v0.4.9-0.20220727151557-61cd9c9353fc) >> grafana.scm
guix import go -r github.com/moby/moby@(v0.7.3-0.20190826074503-38ab9da00309)
>> grafana.scm
guix import go -r github.com/gomodule/redigo@(v1.8.9) >> grafana.scm
guix import go -r github.com/russellhaering/goxmldsig@(v1.1.1) >> grafana.scm
guix import go -r
github.com/grafana/go-mssqldb@(v0.0.0-20210326084033-d0ce3c521036) >>
grafana.scm
guix import go -r gopkg.in/warnings.v0@(v0.1.2) >> grafana.scm
guix import go -r golang.org/x/mod@(v0.7.0) >> grafana.scm
guix import go -r go.opentelemetry.io/proto/otlp@(v0.16.0) >> grafana.scm
guix import go -r
go.opentelemetry.io/otel/exporters/otlp/internal/retry@(v1.7.0) >> grafana.scm
guix import go -r github.com/yudai/pp@(v2.0.1+incompatible) >> grafana.scm
guix import go -r github.com/xlab/treeprint@(v1.1.0) >> grafana.scm
guix import go -r github.com/xanzy/ssh-agent@(v0.3.0) >> grafana.scm
guix import go -r github.com/wk8/go-ordered-map@(v1.0.0) >> grafana.scm
guix import go -r github.com/valyala/fasttemplate@(v1.2.1) >> grafana.scm
guix import go -r github.com/pierrec/lz4/v4@(v4.1.12) >> grafana.scm
guix import go -r github.com/mschoch/smat@(v0.2.0) >> grafana.scm
guix import go -r github.com/mitchellh/go-wordwrap@(v1.0.1) >> grafana.scm
guix import go -r github.com/mitchellh/go-homedir@(v1.1.0) >> grafana.scm
guix import go -r github.com/labstack/gommon@(v0.3.1) >> grafana.scm
guix import go -r github.com/labstack/echo/v4@(v4.9.0) >> grafana.scm
guix import go -r github.com/kylelemons/godebug@(v1.1.0) >> grafana.scm
guix import go -r github.com/klauspost/compress@(v1.15.5) >> grafana.scm
guix import go -r
github.com/kevinburke/ssh_config@(v0.0.0-20201106050909-4977a11b4351) >>
grafana.scm
guix import go -r
github.com/jbenet/go-context@(v0.0.0-20150711004518-d14ea06fba99) >> grafana.scm
guix import go -r github.com/imdario/mergo@(v0.3.12) >> grafana.scm
guix import go -r
Re: Why does setting a language in Grub take 1.5 minutes?
Olivier Dion writes: > On Sun, 15 May 2022, Katherine Cox-Buday wrote: >> At some point, after a long time with no problems, my system began >> taking an unreasonably long time to boot. I only reboot my system >> ~1/week for updates, so I never took the time to debug the problem, >> and therefore, I couldn't really connect the issue with any changes >> that either I or Guix had made. > > I've come across this > https://lists.gnu.org/archive/html/grub-devel/2022-05/msg5.html > today. If it is the problem, perhaps GCing your old kernels would make > the boot faster. Thank you for responding. I think this only impacts running `grub-mkconfig` and not booting, doesn't it? Aside from that, the echo statements I gave suggest that the issue is with setting the language. Still, I removed some old generations of my system. Things went a little faster, but I'm guessing that's probably a side-effect of shrinking my /gnu/store path. Thank you for the suggestion. -- Katherine
Re: Why does setting a language in Grub take 1.5 minutes?
raingloom writes: > On Sun, 15 May 2022 18:06:41 -0500 > Katherine Cox-Buday wrote: > >> At some point, after a long time with no problems, my system began >> taking an unreasonably long time to boot. I only reboot my system >> ~1/week for updates, so I never took the time to debug the problem, >> and therefore, I couldn't really connect the issue with any changes >> that either I or Guix had made. >> >> I'm now trying to debug a wake from hibernate issue, and this >> involves a lot of rebooting, so I had to figure this out. I have, and >> I'm unsure why what I found is causing issues, and whether it's a >> Guix bug, or something wrong with my setup. >> >> Here's my partition layout: >> >> #+begin_example >> $ lsblk >> NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS >> nvme0n1 259:20 931.5G 0 disk >> ├─nvme0n1p1 259:30 549M 0 part /boot/efi >> └─nvme0n1p2 259:40 931G 0 part >> └─cryptroot 253:00 931G 0 crypt /var/lib/docker >>/gnu/store >>/ >> #+end_example >> >> There are no filesystem errors. >> >> Here's the bootloader portion of my operating-system: >> >> #+begin_example >> (bootloader >>(bootloader-configuration >> (bootloader grub-efi-bootloader) >> (targets (list "/boot/efi")) >> (keyboard-layout keyboard-layout))) >> #+end_example >> >> Here's part of my /boot/grub/grub.cfg, generated by Guix. I've added >> some echo statements to help debug. >> >> #+begin_example >> echo "C" >> >> # Set 'root' to the partition that contains /gnu/store. >> search --file --set >> /gnu/store/9lcbyg3pkb38chhv0yzk6hn3arxfjfgk-grub-image.png echo "D" >> >> >> if loadfont unicode; then >> set gfxmode=auto >> insmod all_video >> echo "E" >> insmod gfxterm >> echo "F" >> fi >> >> terminal_output gfxterm >> echo "G" >> >> insmod png >> echo "H" >> if background_image >> /gnu/store/9lcbyg3pkb38chhv0yzk6hn3arxfjfgk-grub-image.png; then echo >> "H.1" set color_normal=light-gray/black >> echo "H.2" >> set color_highlight=yellow/black >> echo "H.3" >> else >> set menu_color_normal=cyan/blue >> set menu_color_highlight=white/blue >> fi >> echo "I" >> Localization configuration. >> search --file --set >> /gnu/store/mdrdpd6aw9ikx1wzx6ljydpzvnvwpq0y-grub-locales/e...@quot.mo >> echo "J" set >> locale_dir=/gnu/store/mdrdpd6aw9ikx1wzx6ljydpzvnvwpq0y-grub-locales >> echo "K" set lang=en_US >> echo "L" >> insmod keylayouts >> echo "M" >> keymap /gnu/store/pgg50qzm7d2q6k0f82c43fmsxwpwrjvx-grub-keymap.us >> echo "N" >> #+end_example >> >> And here are the time elapsed between steps (at least the ones that >> didn't go by too quickly), in seconds: >> >> C -> D : 13 >> H -> I : 13 >> I -> K : 27 >> K -> M : 157 () >> M -> N : 20 >> >> That's almost 4 minutes from unlocking the luks volume to get to the >> Grub menu, and then another 4 minutes to boot into the Kernel. >> >> I then removed the keyboard configuration and changed the theme so >> that it wouldn't load an image: >> >> #+begin_example >> (bootloader >>(bootloader-configuration >> (bootloader grub-efi-bootloader) >> (targets (list "/boot/efi")) >> (theme (grub-theme >> (inherit (grub-theme)) >> (image #f) >> #+end_example >> >> It produces a grub.cfg with this in it (again, echoes added): >> >> #+begin_example >> echo "A" >> set >> locale_dir=/gnu/store/mdrdpd6aw9ikx1wzx6ljydpzvnvwpq0y-grub-locales >> echo "B" set lang=en_US >> echo "C" >> #+end_example >> >> Between B -> C, it still takes 157 seconds. >> >> Does anyone know why this is taking so long or how to fix it? As it >> is, I'll have to manually edit my grub.cfg after every system >> reconfigure. >> >> Thank you, > > A guess: since LUKS seems to be involved, mayyybe it's an entropy > issue? There was a time when booting took a wh
Why does setting a language in Grub take 1.5 minutes?
At some point, after a long time with no problems, my system began taking an unreasonably long time to boot. I only reboot my system ~1/week for updates, so I never took the time to debug the problem, and therefore, I couldn't really connect the issue with any changes that either I or Guix had made. I'm now trying to debug a wake from hibernate issue, and this involves a lot of rebooting, so I had to figure this out. I have, and I'm unsure why what I found is causing issues, and whether it's a Guix bug, or something wrong with my setup. Here's my partition layout: #+begin_example $ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS nvme0n1 259:20 931.5G 0 disk ├─nvme0n1p1 259:30 549M 0 part /boot/efi └─nvme0n1p2 259:40 931G 0 part └─cryptroot 253:00 931G 0 crypt /var/lib/docker /gnu/store / #+end_example There are no filesystem errors. Here's the bootloader portion of my operating-system: #+begin_example (bootloader (bootloader-configuration (bootloader grub-efi-bootloader) (targets (list "/boot/efi")) (keyboard-layout keyboard-layout))) #+end_example Here's part of my /boot/grub/grub.cfg, generated by Guix. I've added some echo statements to help debug. #+begin_example echo "C" # Set 'root' to the partition that contains /gnu/store. search --file --set /gnu/store/9lcbyg3pkb38chhv0yzk6hn3arxfjfgk-grub-image.png echo "D" if loadfont unicode; then set gfxmode=auto insmod all_video echo "E" insmod gfxterm echo "F" fi terminal_output gfxterm echo "G" insmod png echo "H" if background_image /gnu/store/9lcbyg3pkb38chhv0yzk6hn3arxfjfgk-grub-image.png; then echo "H.1" set color_normal=light-gray/black echo "H.2" set color_highlight=yellow/black echo "H.3" else set menu_color_normal=cyan/blue set menu_color_highlight=white/blue fi echo "I" Localization configuration. search --file --set /gnu/store/mdrdpd6aw9ikx1wzx6ljydpzvnvwpq0y-grub-locales/e...@quot.mo echo "J" set locale_dir=/gnu/store/mdrdpd6aw9ikx1wzx6ljydpzvnvwpq0y-grub-locales echo "K" set lang=en_US echo "L" insmod keylayouts echo "M" keymap /gnu/store/pgg50qzm7d2q6k0f82c43fmsxwpwrjvx-grub-keymap.us echo "N" #+end_example And here are the time elapsed between steps (at least the ones that didn't go by too quickly), in seconds: C -> D : 13 H -> I : 13 I -> K : 27 K -> M : 157 () M -> N : 20 That's almost 4 minutes from unlocking the luks volume to get to the Grub menu, and then another 4 minutes to boot into the Kernel. I then removed the keyboard configuration and changed the theme so that it wouldn't load an image: #+begin_example (bootloader (bootloader-configuration (bootloader grub-efi-bootloader) (targets (list "/boot/efi")) (theme (grub-theme (inherit (grub-theme)) (image #f) #+end_example It produces a grub.cfg with this in it (again, echoes added): #+begin_example echo "A" set locale_dir=/gnu/store/mdrdpd6aw9ikx1wzx6ljydpzvnvwpq0y-grub-locales echo "B" set lang=en_US echo "C" #+end_example Between B -> C, it still takes 157 seconds. Does anyone know why this is taking so long or how to fix it? As it is, I'll have to manually edit my grub.cfg after every system reconfigure. Thank you, -- Katherine
Re: stumpwm on guix - "sb-cltl2" issues
Wil deBeest writes: > > Wil deBeest writes: > >> >> Benjamin Slade writes: >> >>> I'm trying to run my long-standing stumpwm init.lisp on a recent Guix >>> install, using the packaged stumpwm, however when it launches, it >>> fails to process the init.lisp and gives me an "Don't know how to >>> REQUIRE sb-cltl2." error. >>> I've set the SBCL_HOME variable both in .xprofile and in the init.lisp >>> itself [via `(sb-posix:putenv >>> "SBCL_HOME=/run/current-system/profile/lib/sbcl/")' ], but this >>> doesn't seem to help. >>> Is there a good way around this? (On my other system I just compile >>> stumpwm from source and install; I don't know if that makes a >>> difference here.) >>> —Ben >> >> I used to have the same problem, but I don't remember what fixed it. >> >> SBCL_HOME isn't set at all, I only have `exec >> /home/bovid-19/.guix-profile/bin/stumpwm' in my >> `~/.xinitrc', and my stumpwm init file starts like this: >> >> (in-package :stumpwm) >> (require 'sb-cltl2) >> >> >> I'm not sure what else I can look for. > > I have probably found the solution: in addition to stumpwm, I also have > `cl-trivial-cltl2' and `cl-asdf' (and sbcl) in my system configuration. > If you can confirm that those two packages are what was missing, we > should add them to the stumpwm package as inputs. I think I have this problem? But like Benjamin, it has also been a very long time since I addressed it. In my profiles, I include: "stumpwm" "sbcl-stumpwm-kbd-layouts" ;; net module has this unacknowledged dependency "sbcl-cl-ppcre" "sbcl-stumpwm-net" "sbcl-stumpwm-pass" "sbcl-stumpwm-stumptray" "sbcl-stumpwm-swm-gaps" "sbcl-stumpwm-ttf-fonts" and I don't seem to have any problem. I start it from lightdm, and I don't think that's doing anything special. Probably in my case some of the modules are including the missing dependencies. I hope that helps somehow. -- Katherine
Re: using dpkg-deb in a Guix package definition
Benjamin Slade writes: > Are there any good examples of writing a Guix package definition using dpkg? I'm not sure if this helps, but I had to consume a deb and wrote a package that unpacks it to get the binary: https://github.com/kat-co/guix-channels/blob/non-free/non-free/packages/security.scm#L122-L127= -- Katherine
Re: GNU Guix maintainer rotation
Maxim Cournoyer writes: > I'd like to bring your attention to a change to the current Guix > maintainers collective; in a nutshell, Ludovic and Marius are stepping > down from maintainer-ship while Efraim is joining. Thank you very much for your guidance, support, and hard work, Ludovic and Marius. Likewise, Efraim, thank you for your contributions, and for stepping up! -- Katherine
Re: Loading Common Lisp Libraries with GNU/Guix in a REPL
Edouard Klein writes:
I also don't know the canonical way, but I do it a different way. I'm wondering
what the simpler way to do things is? I know nothing about rlwrap. But here's
how I do things:
Depending on the project, I may have a =guix.scm= package defined for it or
not. This only changes how I invoke =guix shell=, not the technique.
>From emacs, I run slime: with =C-u M-x slime=. It prompts me for which lisp I
>want to run, and then I type =guix shell -D -- sbcl=. This seems pretty simple.
I think I did have to include this in my bash initialization though. I'm not
sure if it will work without it, or if there's a more correct way to do what
I'm doing:
#+begin-src bash
if [ -n "${GUIX_ENVIRONMENT}" ]; then
export XDG_CONFIG_DIRS="${GUIX_ENVIRONMENT}/etc:${XDG_CONFIG_DIRS}"
export XDG_DATA_DIRS="${GUIX_ENVIRONMENT}/share:${XDG_DATA_DIRS}"
export PATH="${GUIX_ENVIRONMENT}/bin:${PATH}"
export PATH="${GUIX_ENVIRONMENT}/sbin:${PATH}"
fi
#+end_src
I hope this helps!
--
Katherine
Re: packaging a golang package
Hello again, François! I've redirected this thread to guix-devel, and the bug since we've begun discussing implementation details. JOULAUD François writes: > First is to use vendored dependencies (when upstream provides them). This > one has the merits of simplicity (as we just have to download the > source and launch `go build` or whatever is needed) and less risks of > bugs. The downsides are known: difficult to audit Licences, duplication > of code source, difficulty to follow security bugs, etc. -1 to this approach (explanation below). > Second is to re-vendor package from go.mod (coming directly from code > source or synthetized from source) by creating a source derivation > including all dependencies. This is the strategy followed by Nixpkgs > as explained in [1]. (It seems to me this is the route followed in > the patches to from Helio in [2] but I did not take the time to read > them.) With this approach we still have some of the downsides of using > vendored upstream but it is at least easier to verify the existence > of upstream. I don't fully understand this approach, so I don't understand how this is different to approach three? Does this mean we create a pseudo, non-public package which states all the dependencies as inputs? If so, why wouldn't we just go with option three? > Third is to package every dependencies. This is the most transparent way > and the one that leads to less code duplication but the downside is the > difficulty to scale with the number of packages (even if the objective of > patch at [3] is to automate it) and the need to have only one reference > version for each package in the distribution which have its own share of > problems (one of them being that we don't use those tested by upstream > as stated in [4]). I think this is the eternal conflict between distributions and code-bases. As a software engineer, I am a fan of vendoring. It removes entire classes of issues: - Dependency on remote servers to be up to fetch dependencies and perform builds - Requiring some kind of system to pin versions - Needing to stay on top of releases even if that doesn't meet your schedule or needs As a packager for a distribution, I dislike vendoring because of the reasons you outlined above, _but_ I also dislike building upstream software with versions of dependencies that weren't approved, tested, and verified, upstream. It seems to me like that's a recipe for unstable, maybe even insecure, software. Normally, distributions are forced to do this because their packaging and build systems are only set up to support one version at a time. Guix can theoretically support all versions, but doesn't want to take on the dependency graph explosion this approach would cause. If we go on historical precedent, and how Guix handles the other language ecosystems, we should only have one version of each dependency, and build all software which relies on that dependency on the version we have packaged. Guix has already begun taking on the difficult challenges with this approach, including patching upstream to work with versions of dependencies upstream was not built for. I dislike it, but I also don't think we should try to solve the broader class of issues while trying to implement an importer. It should be a larger discussion within the Guix community across _all_ language packages about how we might achieve upstream parity while still maintaining our goals as a distribution, all while not crippling our infrastructure and people :) That's my viewpoint, but I think we should all defer to some of the longer-term maintainers who have helped guide Guix. Thanks for writing up these options. -- Katherine
Re: stumpwm contrib modules have been broken
Guillaume Le Vaillant writes: > Guillaume Le Vaillant skribis: > >> Katherine Cox-Buday skribis: >> >>> Sometime recently, the way Common Lisp code is compiled was changed (for >>> the better, I think), and now my StumpWM contrib modules won't load. >>> Here's why: >>> >>> StumpWM looks[1] for .asd files to determine what is a module. Guix's >>> Common Lisp build system used to combine an entire system into a single >>> .fasl file and then produce a .asd file for loading it. Now -- as far as >>> I can tell -- it looks like `lib/common-lisp/sbcl` is more like the >>> Common Lisp cache: one .fasl file per .lisp file. >>> >>> If I point StumpWM at `lib/common-lisp/sbcl` via `set-module-dir`, it >>> finds no modules. If I point StumpWM at `share/common-lisp/sbcl`, it >>> finds modules, tries to compile them, and then gives me a permissions >>> error about writing to the `/gnu` store. >>> >>> Is anyone using StumpWM contrib modules successfully with Guix's new >>> layout? How? >>> >>> [1] - https://github.com/stumpwm/stumpwm/blob/master/module.lisp#L70 >> >> Hi, Hey, thanks for responding Guillaume, and thanks for forwarding, Pierre. >> In my StumpWM init file, I use '(asdf:load-system ...)' instead of >> '(load-module ...)' to load the contrib modules that are installed in my >> Guix profile, and it works. When I try this, I get this error: Error opening #P"/gnu/store/j6s3hhmlm8n7ynv92agcbzzxrc0bgpc0-stumpwm-20.11-lib/lib/common-lisp/sbcl/stumpwm/package-tmpAAURS01.fasl which is a file that does not exist. > With the following near the top of my StumpWM init file, the > 'load-module' function works like 'asdf:load-system': > > (let* ((guix-profile (pathname-as-directory (getenv "GUIX_PROFILE"))) >(module-dir (merge-pathnames "share/common-lisp/sbcl/" guix-profile))) > (set-module-dir module-dir)) This is what I mentioned above, pointing to the `share/` side of things. On my Guix OS system, this works (but it has to compile everything; I'd prefer to use the precompiled fasls), but on my alien distro, I get the afforementioned permission error as it tries to write to the store. I'm happy to try and find something that works in the short-term so I can get my window manager back, but in the long-term, we should repair the bug so that new users aren't left wondering as well. Thanks again for responding. Katherine
How can I have a static IP on one NIC and DHCP on the other?
Is it possible to define an operating-system which runs DHCP on one NIC, and has a static address on the other? I'm getting: guix system: error: service 'networking' provided more than once if i try and define service for dhcp-client-service-type and static-networking-service. -- Katherine
stumpwm contrib modules have been broken
Sometime recently, the way Common Lisp code is compiled was changed (for the better, I think), and now my StumpWM contrib modules won't load. Here's why: StumpWM looks[1] for .asd files to determine what is a module. Guix's Common Lisp build system used to combine an entire system into a single .fasl file and then produce a .asd file for loading it. Now -- as far as I can tell -- it looks like `lib/common-lisp/sbcl` is more like the Common Lisp cache: one .fasl file per .lisp file. If I point StumpWM at `lib/common-lisp/sbcl` via `set-module-dir`, it finds no modules. If I point StumpWM at `share/common-lisp/sbcl`, it finds modules, tries to compile them, and then gives me a permissions error about writing to the `/gnu` store. Is anyone using StumpWM contrib modules successfully with Guix's new layout? How? [1] - https://github.com/stumpwm/stumpwm/blob/master/module.lisp#L70 -- Katherine
Re: Problems with McCLIM (Common Lisp)
Pierre Neidhardt writes: > Konrad Hinsen writes: > >> That sounds good, as does getting rid of ADSF bundles. I have more or >> less given up on numcl, for example, which fails to compile to a bundle >> in recent versions but seems to work find via fasls (at least it works >> fine with quicklisp). > > It seems that the Common Lisp community is mostly relying on Quicklisp > and thus rarely, if ever, uses asdf:compile-bundle-op. > The latter has been a source of oddities to me: several times a piece of > code would behave differently between compile-bundle-op and compile-op. > Upstream is almost always relying on compile-op and thus not aware of > the compile-bundle-op issues. It's been awhile since I packaged any new Common Lisp systems into Guix, but I most often experienced this with the new package-inferred style of systems (you can probably find my messages in the guix-devel archives). To try and side-step the aforementioned issues with Guix's bundling code, I tried using the compile-bundle-op operation and a few others, and none of them worked with package-inferred systems. I believe I did some research and found that there was some esoteric reason these operations didn't work with package-inferred systems. I would be delighted if they did. We do need to overhaul how we package Common Lisp software in general. Regardless of whether the functionality we're discussing works, I think we have many more "standard" options for laying out packages and fasls on disk. We might want to consider looking closely at what Quicklisp does and see if we can't map that onto the store. I'm glad people like Pierre are looking into this! I wish I had more time to help at the moment, but: 2020. -- Katherine
Re: need help with cl packaging
Adam Kandur via writes: > Maybe somebody had same issue with common lisp packaging? We've got a few lispers around with packaging experience (Pierre being an awesome one!). In the future, please consider directing packaging questions to guix-de...@gnu.org. -- Katherine
Re: GNU Guix 1.0.0 released
Christopher Lemmer Webber writes: > Ludovic Courtès writes: > >> We are thrilled to announce the release of GNU Guix 1.0.0! > > Massive congrats to the whole Guix community! Woohoo :) Congratulations, everyone! Thank you for all of your hard work. Guix has a great community, and awesome tech. Here's to many more releases! -- Katherine
Re: Getting rid of "source file [...] newer than compiled" messages
Giovanni Biscuolo writes: > synoacl? I cannot find that mount option: are you on a Synology NAS? Yes. > AFAIK stripe=32 should not have any impact on mtime, nor data=writeback > > I'm using Guix on Debian and my store is in a LV too: > > /dev/mapper/vg01-gnu on /gnu type ext4 (rw,relatime) Hm, OK. That was my best guess. > I vaguely recall once I had one problem with source scm files newer than > compiled when using ./pre-inst-env (for sure I did something wrong > hacking, not directly touching /gnu/store anyway) but "guix gc > --verify=repair" fixed that for me This was my expectation too! I am perplexed as to why it doesn't. > Ricardo also asked you about the daemon: how is it started on your > machine? Synology's distro remains on upstart which is what I'm using to start the daemon: #+BEGIN_EXAMPLE $ ps -fC guix-daemon UIDPID PPID C STIME TTY TIME CMD root 27071 1 0 Apr06 ?00:00:00 guix-daemon --build-users-group=guixbuild #+END_EXAMPLE > HTH! Gio' Thank you! -- Katherine
Re: Getting rid of "source file [...] newer than compiled" messages
Ricardo Wurmus writes: > Maybe. But subsequent calls to “guix pull” should give you new store > items anyway, and those should be fine. That's odd. I have definitely run `guix pull` several times on this machine. > Is there anything special about your setup perhaps? E.g. running the > daemon as some other user than root, using btrfs, etc. The store is mounted on a RAID-6 array with an ext4 filesystem. Maybe the striping is confusing things? Here's the mount point: #+BEGIN_EXAMPLE $ mount |grep gnu /dev/mapper/vg1-volume_2 on /gnu type ext4 (rw,relatime,synoacl,stripe=32,data=writeback,jqfmt=vfsv0,usrjquota=aquota.user,grpjquota=aquota.group) #+END_EXAMPLE >> I still hold the opinion that the guix toolchain should be able to heal >> store items, regardless of how they got that way, or whether it should >> be theoretically possible. Do you disagree? > > No, I agree with you. That’s one of the reasons why “guix gc > --verify=repair,contents” exists. Hm, does this also look at timestamps? Why didn't this give me any output or fix the issue? -- Katherine
Re: Getting rid of "source file [...] newer than compiled" messages
Ricardo Wurmus writes: > Katherine Cox-Buday writes: > >> Gosh, I am embarassed. The compiled files are indeed in the path Guile >> was helpfully trying to point me at: >> >> #+BEGIN_EXAMPLE >> $ ls -a >> /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/ >> . .. base16.go base64.go common.go hash.go hmac.go >> package-config.go pk-crypto.go random.go utils.go >> #+END_EXAMPLE >> >> So I went back and took Ricardo's advice and looked at the time's involved: >> >> #+BEGIN_EXAMPLE >> $ stat >> /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt/hash.scm >> File: >> ‘/gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt/hash.scm’ >> Size: 5366 Blocks: 16 IO Block: 4096 regular file >> Device: fc02h/64514d Inode: 137942 Links: 1 >> Access: (0444/-r--r--r--) Uid: (0/root) Gid: (0/root) >> Access: 2019-04-10 09:29:22.00969 -0500 >> Modify: 2018-12-25 17:02:43.755150339 -0600 >> Change: 2018-12-25 17:02:43.755150339 -0600 >>Birth: - >> #+END_EXAMPLE >> >> #+BEGIN_EXAMPLE >> $ stat >> /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/hash.go >> File: >> ‘/gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/hash.go’ >> Size: 77485 Blocks: 152IO Block: 4096 regular file >> Device: fc02h/64514d Inode: 137925 Links: 1 >> Access: (0444/-r--r--r--) Uid: (0/root) Gid: (0/root) >> Access: 2019-04-06 16:56:32.259721626 -0500 >> Modify: 2018-12-25 17:02:43.753150336 -0600 >> Change: 2018-12-25 17:02:43.753150336 -0600 >>Birth: - >> #+END_EXAMPLE >> >> It looks like the scheme file is fractions of a second newer than the >> compiled file. So, pulling on this thread: > > These time stamps are wrong. Everything in /gnu/store should have 0 for > the mtime. Perhaps I missed a flag when unpacking the store initially? > >> 2. I feel like, regardless of the root-cause, some Guix command should >>be able to correct this issue for me, without necessarily having to >>know what went wrong or why. > > This shouldn’t ever happen, because all store items should have their > mtime reset. > > You previously mentioned that you modified your store (which “voids your > warranty” as it were); by default the store is bind-mounted to ensure > that it is read-only. Can you tell us more about the file system and > the way the store is mounted? I previously mentioned I was considering modifying the store as a fix to this issue. To my recollection, I don't think I've manually touched the store yet. I still hold the opinion that the guix toolchain should be able to heal store items, regardless of how they got that way, or whether it should be theoretically possible. Do you disagree? -- Katherine
Re: Getting rid of "source file [...] newer than compiled" messages
Andreas Enge writes: > Hello, > > On Wed, Apr 10, 2019 at 09:31:03AM -0500, Katherine Cox-Buday wrote: >> Ricardo Wurmus writes: >> >> > You said that there are no .go files, yet Guile keeps saying that the >> > source file >> > /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt/hash.scm >> > is newer than the compiled >> > /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/hash.go >> > >> > Does the second file really not exist while the first one does? >> >> Correct: >> >> #+BEGIN_EXAMPLE >> ls -a >> /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt >> . .. base16.scm base64.scm common.scm hash.scm hmac.scm >> package-config.scm pk-crypto.scm random.scm utils.scm >> #+END_EXAMPLE > > notice that the .go file is in a different subdirectory of the package > directory. Gosh, I am embarassed. The compiled files are indeed in the path Guile was helpfully trying to point me at: #+BEGIN_EXAMPLE $ ls -a /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/ . .. base16.go base64.go common.go hash.go hmac.go package-config.go pk-crypto.go random.go utils.go #+END_EXAMPLE So I went back and took Ricardo's advice and looked at the time's involved: #+BEGIN_EXAMPLE $ stat /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt/hash.scm File: ‘/gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt/hash.scm’ Size: 5366 Blocks: 16 IO Block: 4096 regular file Device: fc02h/64514d Inode: 137942 Links: 1 Access: (0444/-r--r--r--) Uid: (0/root) Gid: (0/root) Access: 2019-04-10 09:29:22.00969 -0500 Modify: 2018-12-25 17:02:43.755150339 -0600 Change: 2018-12-25 17:02:43.755150339 -0600 Birth: - #+END_EXAMPLE #+BEGIN_EXAMPLE $ stat /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/hash.go File: ‘/gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/hash.go’ Size: 77485 Blocks: 152IO Block: 4096 regular file Device: fc02h/64514d Inode: 137925 Links: 1 Access: (0444/-r--r--r--) Uid: (0/root) Gid: (0/root) Access: 2019-04-06 16:56:32.259721626 -0500 Modify: 2018-12-25 17:02:43.753150336 -0600 Change: 2018-12-25 17:02:43.753150336 -0600 Birth: - #+END_EXAMPLE It looks like the scheme file is fractions of a second newer than the compiled file. So, pulling on this thread: 1. This looks like this has been an issue since I installed Guix. Did I do something wrong? 2. I feel like, regardless of the root-cause, some Guix command should be able to correct this issue for me, without necessarily having to know what went wrong or why. Thank you all! And thoughts? -- Katherine
Re: Getting rid of "source file [...] newer than compiled" messages
Ricardo Wurmus writes: > You said that there are no .go files, yet Guile keeps saying that the > source file > /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt/hash.scm > is newer than the compiled > /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/hash.go > > Does the second file really not exist while the first one does? Correct: #+BEGIN_EXAMPLE ls -a /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt . .. base16.scm base64.scm common.scm hash.scm hmac.scm package-config.scm pk-crypto.scm random.scm utils.scm #+END_EXAMPLE -- Katherine
Re: Getting rid of "source file [...] newer than compiled" messages
Ricardo Wurmus writes: > Oh, well, that’s definitely not right. Guix does not download > individual files when fetching packages — it downloads archives that > definitely do contain the .go files. So the question is… where did they > go once “guix pull” finished? Yeah, I don't know! Mostly I'm trying to dig into this edge-case of trying to get malformed packages back into a known state. I imagine that will come up from time to time on users' machines, for various reasons. > Does “guix gc --verify=repair,contents” (run as root) really not tell > you anything useful? Here is the output, verbatim: #+BEGIN_EXAMPLE sudo guix gc --verify=repair,contents Password: guile: warning: failed to install locale ;;; note: source file /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt/hash.scm ;;; newer than compiled /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/hash.go ;;; note: source file /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt/common.scm ;;; newer than compiled /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/common.go ;;; note: source file /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt/package-config.scm ;;; newer than compiled /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/package-config.go ;;; note: source file /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt/utils.scm ;;; newer than compiled /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/utils.go reading the store... checking path existence... checking hashes... Some deprecated features have been used. Set the environment variable GUILE_WARN_DEPRECATED to "detailed" and rerun the program to get more information. Set it to "no" to suppress this message. #+END_EXAMPLE So, unfortunately not :( And these messages continue. As a user, I would have definitely expected this command to have found an issue. -- Katherine
Re: Getting rid of "source file [...] newer than compiled" messages
Ricardo Wurmus writes: > This is really odd and I cannot reproduce this. I wonder if this might > be related to some unusual file system choices or settings that cause > Guile to think that the source files are more recent. I have accepted that I have somehow gotten myself into a dark corner of Guix! I was expecting there to be a Guix command that would basically get any package back into a good state. I was kind of surprised that `guix build --check` or `guix build --repair` didn't help me out. My expectation was that maybe this would check the hash of the store with upstream and rebuild or redownload a substitute. > Can you show us the mtime of these files? In my case both the scm and > the go files all have their mtime as 1970-01-01 01:00:01.0 > +0100. One interesting point might be that there are no `.go` files. I would argue Guile's error message here could use some care, but even a better error message won't get me to a better spot :) Thanks again for the time, Ricardo. -- Katherine
Re: Getting rid of "source file [...] newer than compiled" messages
I was wondering if anyone had any ideas? This is not blocking me from doing anything, but it does cause a lot of spam, and it slows operations down a lot. Katherine Cox-Buday writes: > Ricardo Wurmus writes: > >> Katherine Cox-Buday writes: >> >>> I'm not using Guix from a source checkout. I've issued `guix pull` >>> (both >>> under the root account and as my user account) a few times with no >>> change. >> >> Hmm, this should never leave you with an uncompiled Guix. Can you tell >> us more about the environment in which this happens? (e.g. the output >> of “env” will be fine.) > > Here is an example. When I run `guix help` I receive: > > #+BEGIN_EXAMPLE > ;;; note: source file > /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt/hash.scm > ;;; newer than compiled > /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/hash.go > ;;; note: source file > /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt/common.scm > ;;; newer than compiled > /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/common.go > ;;; note: source file > /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt/package-config.scm > ;;; newer than compiled > /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/package-config.go > ;;; note: source file > /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt/utils.scm > ;;; newer than compiled > /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/utils.go > #+END_EXAMPLE > > > `env` reports: > > #+BEGIN_EXAMPLE > GUIX_LOCPATH=/var/services/homes/me/.guix-profile/lib/locale > TERM=xterm-256color > SHELL=/bin/sh > SSH_CLIENT=[redacted ip] 41856 22 > SSH_TTY=/dev/pts/9 > LC_ALL=en_US.utf8 > USER=me > GUIX_PROFILE=/var/services/homes/me/.guix-profile > PAGER=more > MAIL=/var/mail/me > > PATH=/var/services/homes/me/.guix-profile/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/syno/sbin:/usr/syno/bin:/usr/local/sbin:/usr/local/bin > PWD=/var/services/homes/me > LANG=en_US.utf8 > SHLVL=1 > HOME=/var/services/homes/me > TERMINFO=/usr/share/terminfo > LOGNAME=me > SSH_CONNECTION=[redacted ip] 41856 [redacted ip] 22 > PGDATA=/var/services/pgsql > XDG_RUNTIME_DIR=/var/services/homes/me/.local/run > GIT_EXEC_PATH=/var/services/homes/me/.guix-profile/bin > _=/bin/env > #+END_EXAMPLE > >>> `guix` is symlinked from `/usr/local/bin/guix` to >>> `/var/guix/profiles/per-user/root/current-guix/bin/guix` which >>> points to >>> the latest profile (which is updated when running `guix pull` as root. >> >> When using “guix pull” it will install into the current user’s >> ~/.config/guix/current/. Are you only using Guix as the root user? > > No, I always use my user account, but root contains the symlinks for the > daemon and CLI. The symlink for `/usr/local/bin/guix` is there from > installation per step (6) of the manual[1]. I tried running `guix pull` > as root because running it under my user account wasn't doing anything. > > Thank you for troubleshooting this with me. > > [1] - > https://www.gnu.org/software/guix/manual/en/html_node/Binary-Installation.html#Binary-Installation -- Katherine
Re: Getting rid of "source file [...] newer than compiled" messages
Ricardo Wurmus writes: > Katherine Cox-Buday writes: > >> I'm not using Guix from a source checkout. I've issued `guix pull` (both >> under the root account and as my user account) a few times with no >> change. > > Hmm, this should never leave you with an uncompiled Guix. Can you tell > us more about the environment in which this happens? (e.g. the output > of “env” will be fine.) Here is an example. When I run `guix help` I receive: #+BEGIN_EXAMPLE ;;; note: source file /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt/hash.scm ;;; newer than compiled /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/hash.go ;;; note: source file /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt/common.scm ;;; newer than compiled /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/common.go ;;; note: source file /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt/package-config.scm ;;; newer than compiled /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/package-config.go ;;; note: source file /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt/utils.scm ;;; newer than compiled /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/utils.go #+END_EXAMPLE `env` reports: #+BEGIN_EXAMPLE GUIX_LOCPATH=/var/services/homes/me/.guix-profile/lib/locale TERM=xterm-256color SHELL=/bin/sh SSH_CLIENT=[redacted ip] 41856 22 SSH_TTY=/dev/pts/9 LC_ALL=en_US.utf8 USER=me GUIX_PROFILE=/var/services/homes/me/.guix-profile PAGER=more MAIL=/var/mail/me PATH=/var/services/homes/me/.guix-profile/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/syno/sbin:/usr/syno/bin:/usr/local/sbin:/usr/local/bin PWD=/var/services/homes/me LANG=en_US.utf8 SHLVL=1 HOME=/var/services/homes/me TERMINFO=/usr/share/terminfo LOGNAME=me SSH_CONNECTION=[redacted ip] 41856 [redacted ip] 22 PGDATA=/var/services/pgsql XDG_RUNTIME_DIR=/var/services/homes/me/.local/run GIT_EXEC_PATH=/var/services/homes/me/.guix-profile/bin _=/bin/env #+END_EXAMPLE >> `guix` is symlinked from `/usr/local/bin/guix` to >> `/var/guix/profiles/per-user/root/current-guix/bin/guix` which points to >> the latest profile (which is updated when running `guix pull` as root. > > When using “guix pull” it will install into the current user’s > ~/.config/guix/current/. Are you only using Guix as the root user? No, I always use my user account, but root contains the symlinks for the daemon and CLI. The symlink for `/usr/local/bin/guix` is there from installation per step (6) of the manual[1]. I tried running `guix pull` as root because running it under my user account wasn't doing anything. Thank you for troubleshooting this with me. [1] - https://www.gnu.org/software/guix/manual/en/html_node/Binary-Installation.html#Binary-Installation -- Katherine
Re: Getting rid of "source file [...] newer than compiled" messages
Ricardo Wurmus writes: > Katherine Cox-Buday writes: > >> I have a Guix installation on a foreign distro, and with most any Guix >> command I receive this message for different packages (depending on what >> command is run). I looked at one package and found that there were no >> `.go` files for the `.scm` files which are listed. > > How did you install Guix? It's been awhile now, but I'm pretty sure I followed the manual and used the bash script. >> Is there a supported way to get rid of these issues? Right now my plan >> is to manually go into the store and use guile to compile these fields, >> and I'd really rather not muck with the store! > > You should never change files in the store. > > The recommended way is to use “guix pull”, which compiles Guix. If > you’re using Guix from a source checkout and with ’pre-inst-env’ you’ll > only need to compile the files with “make” to remove the reason for > these warnings to be issued. I'm not using Guix from a source checkout. I've issued `guix pull` (both under the root account and as my user account) a few times with no change. `guix` is symlinked from `/usr/local/bin/guix` to `/var/guix/profiles/per-user/root/current-guix/bin/guix` which points to the latest profile (which is updated when running `guix pull` as root. Even commands which do not submit jobs to the daemon give this error. Do I need to `guix package -i guix` to get a good version? -- Katherine
Getting rid of "source file [...] newer than compiled" messages
I have a Guix installation on a foreign distro, and with most any Guix command I receive this message for different packages (depending on what command is run). I looked at one package and found that there were no `.go` files for the `.scm` files which are listed. I tried a few different things to try and correct this including `guix build --repair`, but I nothing has worked. Is there a supported way to get rid of these issues? Right now my plan is to manually go into the store and use guile to compile these fields, and I'd really rather not muck with the store! -- Katherine
