[SOLVED] Re: texlive kpathsea ignores TEXMFHOME
Le Sat, May 11, 2024 at 04:13:23PM +0200, Nicolas Goaziou via a écrit :
> Hello,
Hello Nicolas and thank you for the workaround and for the upcomming
fix !
> Indeed. I fixed this issue in "tex-team" branch.
>
> Meanwhile, you may set TEXMF environment variable to
> "'{$TEXMFHOME,$TEXMFDIST}'"
#+begin_example
$ kpsewhich "lettre-default.cfg"
/home/fulbert/.guix-profile/share/texmf-dist/tex/latex/lettre/lettre-default.cfg
$ TEXMF='{$TEXMFHOME,$TEXMFDIST}' kpsewhich "lettre-default.cfg"
/home/fulbert/texmf/tex/latex/lettre/lettre-default.cfg
#+end_example
Workaround tested and approved ;-)
Regards,
Fulbert
texlive kpathsea ignores TEXMFHOME
Hello ! As the little shell session illustrates below, 'kpathsea' fails to search/find files in TEXMFHOME on my “Guix system” setup . Anyone else having the same problem ? Any suggestion ? #+begin_example $ ls -l $(kpsewhich -var-value TEXMFHOME)/**/lettre-default.cfg -rw-r--r-- 1 fulbert users 2034 4 mai 20:11 /home/fulbert/texmf/tex/latex/lettre/lettre-default.cfg $ $ kpsewhich lettre-default.cfg /home/fulbert/.guix-profile/share/texmf-dist/tex/latex/lettre/lettre-default.cfg $ $ guix package --list-installed | grep texlive | cut -f1 texlive-scheme-basic texlive-lettre texlive-collection-latexextra texlive-collection-latex texlive-collection-xetex texlive-collection-latexrecommended texlive-collection-fontsrecommended texlive-collection-langfrench … #+end_example
Re: system hangs at boot - LUKS /home/ problem(?)
( https://issues.guix.gnu.org/70051 )
Re: system hangs at boot - LUKS /home/ problem(?)
Le Wed, Mar 27, 2024 at 10:39:36AM +0100, Adrien 'neox' Bourmault a écrit : > Le mardi 26 mars 2024 à 18:58 +0100, Fulbert a écrit : > > I forgot to mention : LUKS version 2 with PBKDF: argon2i. I remember reading > > that guix supported LUKS2 except for /boot… but I might be wrong. At > > least it > > has worked for month on my computer until guix d5f857a (22 mar 2024). > > > > So, new question, do I have to convert to LUKS1 ? > > > > Le 26.03.24 à 16:15, Fulbert a écrit : > > > > > Hello! Seeking some help/suggestions to solve a problem preventing > > > my system to boot up, which was working properly up to guix 9b84b36 > > > (21 mar 2024) (note: I confess that my system is not totally pure). > > > > > > Starting with guix d5f857a (22 mar 2024) up to my latest guix pull > > > with 1415ea7, the **system hangs during boot**, and it does before > > > anything is written to /var/log/messages. So, using a video capture > > > of the screen at boot, I was abble to catch : > > > > > > #+begin_src boot > > > shepherd[1]: Exception caught while while starting > > > device-mapping-luks-homes: > > > (unbound-variable #f "Unbound variable: "S" (bytevector?) #f) > > > #+end_src > > > > > > … which appears to be the culprit ?! > > > > > > follows a long list of "shepherd[1]: Service XXX depends on YYY" and > > > then > > > #+begin_src boot > > > shepherd[1]: The following services could not be started in the > > > background: > > > > > > #+end_src > > > > > > From there : a blinking cursor and the only way out I found is > > > CTRL-ALT-DEL, which triggers shepherd to stop some services. After > > > that I have to shutdown using hardware button. > > > > > > My system and its config.scm have not changed and I see nothing > > > relevant, related to LUKS/dm-crypt, in `guix pull -l`. > > > > > > My LUKS is configured like so : > > > > > > (mapped-devices > > > (list > > > (mapped-device > > > (source (uuid "")) > > > (target "luks-homes") > > > (type luks-device-mapping > > > > > > (file-systems > > > (append > > > (list > > > […] > > > (file-system (mount-point "/home") > > > (device (file-system-label "luks-homes")) > > > (type "ext4") > > > (dependencies mapped-devices)) > > > […] > > > > > > Any help would be appreciated. > > > > > > > Hi everyone, the exact same thing happens to me too since d5f857a. > > I'm using a pure GNU Guix installation with my /home as a LUKS partition. > > My fs configuration : > > (file-systems (cons* > (file-system > (mount-point "/home") > (device "/dev/mapper/crypthome") > (type "ext4") > (dependencies mapped-devices)) > (file-system > (mount-point "/boot/efi") > (device (uuid "A012-A17A" 'fat32)) > (type "vfat")) > (file-system > (mount-point "/") > (device (uuid "dfaec018-b99b-4d34-a206-eec25b833c45" 'ext4)) > (type "ext4")) %base-file-systems))) > > Happy hacking! > -- > Adrien Bourmault > Maintainer, GNU Boot project > Associate member, Free Software Foundation > GPG : 393D4CC68136F39799DA75F295F65F55F682A17A > > Hello Adrien and everyone, I have tried to transfer my /home data to a brand new LUKS1 partition, (as well as removing pointers to the old LUKS2 partition in my config.scm, of course) and the problem remains exactly the same, including those error messages (obtained with a video capture of the screen at boot, after removing 'quiet' from the kernel command line in grub) : #+begin_src boot shepherd[1]: Starting service device-mapping-luks-homes... shepherd[1]: Service device-mapping-luks-homes failed to start. shepherd[1]: Exception caught while starting device-mapping-luks-homes: (unbound-variable #f "Unbound variable: "S" (bytevector?) #f) #+end_src Maybe it's worth mentionning that I have tried one configuration of the 'mapped-device' with 'luks-device-mapping' and another one with 'luks-device-mapping-with-options #:keyfile "/…"'. I also tried one configuration with the 'source' declared in plain "/dev/..." and another one declared with the luks '(uuid "…")', just in case. So, although I have learned in the process that LUKS2 is not yet fully supported in guix, this problem also prevents booting using a LUKS1 /home partition… at least in my case… and I am surprised that we are only 2 to report about this, here. Transfering the /home data to a clear (unencrypted) partition is my current workaround to this problem. Any suggestion still welcome, but I suppose the next step should be to send a bug report, in due form.
Re: system hangs at boot - LUKS /home/ problem(?)
I forgot to mention : LUKS version 2 with PBKDF: argon2i. I remember reading that guix supported LUKS2 except for /boot… but I might be wrong. At least it has worked for month on my computer until guix d5f857a (22 mar 2024). So, new question, do I have to convert to LUKS1 ? Le 26.03.24 à 16:15, Fulbert a écrit : Hello! Seeking some help/suggestions to solve a problem preventing my system to boot up, which was working properly up to guix 9b84b36 (21 mar 2024) (note: I confess that my system is not totally pure). Starting with guix d5f857a (22 mar 2024) up to my latest guix pull with 1415ea7, the **system hangs during boot**, and it does before anything is written to /var/log/messages. So, using a video capture of the screen at boot, I was abble to catch : #+begin_src boot shepherd[1]: Exception caught while while starting device-mapping-luks-homes: (unbound-variable #f "Unbound variable: "S" (bytevector?) #f) #+end_src … which appears to be the culprit ?! follows a long list of "shepherd[1]: Service XXX depends on YYY" and then #+begin_src boot shepherd[1]: The following services could not be started in the background: #+end_src From there : a blinking cursor and the only way out I found is CTRL-ALT-DEL, which triggers shepherd to stop some services. After that I have to shutdown using hardware button. My system and its config.scm have not changed and I see nothing relevant, related to LUKS/dm-crypt, in `guix pull -l`. My LUKS is configured like so : (mapped-devices (list (mapped-device (source (uuid "")) (target "luks-homes") (type luks-device-mapping (file-systems (append (list […] (file-system (mount-point "/home") (device (file-system-label "luks-homes")) (type "ext4") (dependencies mapped-devices)) […] Any help would be appreciated.
system hangs at boot - LUKS /home/ problem(?)
Hello! Seeking some help/suggestions to solve a problem preventing my system to boot up, which was working properly up to guix 9b84b36 (21 mar 2024) (note: I confess that my system is not totally pure). Starting with guix d5f857a (22 mar 2024) up to my latest guix pull with 1415ea7, the **system hangs during boot**, and it does before anything is written to /var/log/messages. So, using a video capture of the screen at boot, I was abble to catch : #+begin_src boot shepherd[1]: Exception caught while while starting device-mapping-luks-homes: (unbound-variable #f "Unbound variable: "S" (bytevector?) #f) #+end_src … which appears to be the culprit ?! follows a long list of "shepherd[1]: Service XXX depends on YYY" and then #+begin_src boot shepherd[1]: The following services could not be started in the background: #+end_src >From there : a blinking cursor and the only way out I found is CTRL-ALT-DEL, which triggers shepherd to stop some services. After that I have to shutdown using hardware button. My system and its config.scm have not changed and I see nothing relevant, related to LUKS/dm-crypt, in `guix pull -l`. My LUKS is configured like so : (mapped-devices (list (mapped-device (source (uuid "")) (target "luks-homes") (type luks-device-mapping (file-systems (append (list […] (file-system (mount-point "/home") (device (file-system-label "luks-homes")) (type "ext4") (dependencies mapped-devices)) […] Any help would be appreciated.
user profile problem? : ACL for archive imports seems to be uninitialized
Hello! I had a 2 months+ break away from Guix and I am trying to upgrade it now. I was able to `guix pull` as well as `…system reconfigure…` (and reboot) and my system runs with no apparent problem on this fresh upgrade. But trying to upgrade my default user profile I get this warning : `substitute: guix substitute: warning: ACL for archive imports seems to be uninitialized, substitutes may be unavailable` … and it starts building a list of 300+ packages (including mesboot and gcc related packages, for instance) while `guix weather` gives `looking for 549 store items on https://ci.guix.gnu.org...` `https://ci.guix.gnu.org` `97.8% substitutes available (537 out of 549)`. So, I only have this problem on my user profile and not on the system profile… I would appreciate any help to get my full Guix system upgraded :) Thanks in advance.
Re: Guix REPL - To infinity and beyond
Le Mon, Oct 10, 2022 at 01:00:29PM +0200, Fulbert a écrit : > Le Mon, Oct 10, 2022 at 11:38:38AM +0200, zimoun a écrit : > > Maybe it could be worth to use your note for the Cookbook, WDYT? Hello! To follow up: the proposal for the addition to the Cookbook has been sent. https://issues.guix.gnu.org/58463
Re: Guix REPL - To infinity and beyond
Le Mon, Oct 10, 2022 at 11:38:38AM +0200, zimoun a écrit : > Hi, > > On sam., 08 oct. 2022 at 16:59, Fulbert wrote: > > > So, first, thanks to Simon Fournier for this presentation. And second, as > > it could be convenient not only to self, I made it available there : > > https://fulbert.neocities.org/guix/10-years-of-guix/simon-tournier-guix-repl/guix-repl-exemples.html > > Oh really cool! Thanks! > > I have started a tiny example [1] submitted as patch#58339 [2] where the > aim is to document similarly. You work is far more complete. :-) > > Maybe it could be worth to use your note for the Cookbook, WDYT? > > > 1: <https://gitlab.com/zimoun/guix-example> > 2: <http://issues.guix.gnu.org/issue/58339> > > Cheers, > simon > > > PS: The name is Tournier, with ’T’. Fournier, with ’F’ is someone else. ;-) Hi and my appologies for the name \^^. Of course, if *you* think it is suitable for an entry in the cookbook, who would I be to oppose that ?! :p Although I have never done it, I think it shouldn't be too much work to adapt, convert and integrate to texinfo/cookbook… so, I will make a patch proposal when I'm done with that. Best regards,
Guix REPL - To infinity and beyond
Hello! I wanted to keep the exemples of Guix REPL given by Simon Fournier in his presentation at the 10-years-of-guix event : Guix REPL - to infinity and beyond https://10years.guix.gnu.org/video/guix-repl-to-infinity-and-beyond/ So, first, thanks to Simon Fournier for this presentation. And second, as it could be convenient not only to self, I made it available there : https://fulbert.neocities.org/guix/10-years-of-guix/simon-tournier-guix-repl/guix-repl-exemples.html
Re: bash scripts in Guix question
Le Tue, Oct 04, 2022 at 03:18:36PM +0200, jordi a écrit : > Hi guixers, Hello! > > i'm wondering...for my scripts to work in Guix, instead of > '#! /bin/bash' , > > what do i have to start them with ? #!/usr/bin/env bash And if you need to pass arguments/options, take a look at $ info '(coreutils) env invocation' > Thanks,thanks, thanks Welcome!
Re: duplicate package names in channels
It does help 6/5 ! Thank you for your time and explanation… not to mention the swiftness ! Best regards, Fulbert Le Fri, Sep 30, 2022 at 10:01:39PM +0200, Julien Lepiller a écrit : > Build results are kind of content-addressed, so when two separate packages > yield the same hash, it means they are the same package, and no rebuild is > necessary. > > For the other two questions, it depends from which perspective you're looking > at. From the code point of view, there are no difference between packages > from guix and a channel. When two packages yield a different hash, they are > considered different, so both are built if needed. Also, the code has direct > reference to a given package, you can't reference "whatever provides gcc", > you have to reference a specific gcc package, either from a channel or from > the main guix. > > So from the code point of view, two packages may have the same name and even > version, and this is never ambiguous. Because packages are stored as Guile > variables and when you specify a variable name it can only reference one > value. > > From the user point of view, esp. the CLI, you seem to have noticed that guix > will chose the highest version number when you ask for a package without an > explicit version number. This does not change whether packages come from a > channel or from guix. > > When two packages have the same name and version, guix will arbitrarily (but > reproducibly :p) chose one or the other. > > HTH! > > Le 30 septembre 2022 21:48:31 GMT+02:00, Fulbert a écrit > : > >Hello ! > > > >I'm not sure if guix supports similar package names [and version number] > >provided in more than one “active” channels (declared in the list of > >'~/.config/guix/channels.scm, including %default-channels)… > >a) if 2 packages share their name, version and package definition, > >yielding the exact same result, thus sharing the same hash and > >/gnu/store/ storage-space (one “recognizing” the other hash, avoiding > >redondant build or conflict ?) ; > >b) if 2 packages share their name but not the version, thus yielding > >distinct hashes, could guix automatically choose the highest available > >version, similar to what guix does when it provides multiple versions of > >the same name package in the main 'guix channel ? ; > >c) if 2 packages share their name and version but do not yield the same > >result/hash (… that's the only case where I'm abble to see a conflict). > > > >As far as i understand, (c) would be problematic, thus (a) would require > >a pre-build of both and conflict management, which is unlikely(?) and > >consequently, (b) would require a user to remove manually a package in > >the additionnal channel before it leads to (a). > > > >So, my guess work gives NO, NO and NO, but I would be gratefull if > >someone could confirm, eventually with a pointer to the manual or other > >doc. (I am unable to check that for myself in the sources with any > >degree of comprehension, let alone certainty ^^) > > > >Thanks for guix and best regards, > >Fulbert > >
duplicate package names in channels
Hello ! I'm not sure if guix supports similar package names [and version number] provided in more than one “active” channels (declared in the list of '~/.config/guix/channels.scm, including %default-channels)… a) if 2 packages share their name, version and package definition, yielding the exact same result, thus sharing the same hash and /gnu/store/ storage-space (one “recognizing” the other hash, avoiding redondant build or conflict ?) ; b) if 2 packages share their name but not the version, thus yielding distinct hashes, could guix automatically choose the highest available version, similar to what guix does when it provides multiple versions of the same name package in the main 'guix channel ? ; c) if 2 packages share their name and version but do not yield the same result/hash (… that's the only case where I'm abble to see a conflict). As far as i understand, (c) would be problematic, thus (a) would require a pre-build of both and conflict management, which is unlikely(?) and consequently, (b) would require a user to remove manually a package in the additionnal channel before it leads to (a). So, my guess work gives NO, NO and NO, but I would be gratefull if someone could confirm, eventually with a pointer to the manual or other doc. (I am unable to check that for myself in the sources with any degree of comprehension, let alone certainty ^^) Thanks for guix and best regards, Fulbert
Re: symbolic links for --profile argument
Le Tue, Mar 30, 2021 at 06:42:29AM -0400, Julien Lepiller a écrit :
> The first and third commands are equivalent. I believe the second command
> will replace .guix-profile with a symlink to .guix-profile-1 which will link
> to the store. The last command should fail, because you can't create a store
> item that way.
>
> I think guix environment --profile will create a profile and symlink directly
> to the store, without creating generations. Guix package and its aliases
> (update, remove, install) as well as guix pull create a generation, so their
> --profile option has the same behavior.
>
> HTH!
Hello Julien,
Indeed, it does ! Thanks much for your help.
Best regards,
>
> Le 30 mars 2021 03:49:04 GMT-04:00, Fulbert a écrit :
> >Given
> >
> >~~~{.bash}
> >$ readlink ~/.guix-profile
> >/var/guix/profiles/per-user/fulbert/guix-profile
> >
> >$ readlink -f ~/.guix-profile
> >/gnu/store/2sj11f64c9cgw40gkjy024vjl688zp7k-profile
> >~~~{end}
> >
> >Will the following commands produce exactly the same result ?
> >
> >~~~{.bash}
> >$ guix package -m ~/default.scm
> >$ guix package -m ~/default.scm -p ~/.guix-profile
> >$ guix package -m ~/default.scm -p
> >/var/guix/profiles/per-user/fulbert/guix-profile
> >$ guix package -m ~/default.scm -p
> >/gnu/store/2sj11f64c9cgw40gkjy024vjl688zp7k-profile
> >~~~{end}
> >
> >… and more generally, any guix command taking a `--profile` argument ?
symbolic links for --profile argument
Hello and thanks for visiting my question !
It is a stupid one, but just to be sure :
Given
~~~{.bash}
$ readlink ~/.guix-profile
/var/guix/profiles/per-user/fulbert/guix-profile
$ readlink -f ~/.guix-profile
/gnu/store/2sj11f64c9cgw40gkjy024vjl688zp7k-profile
~~~{end}
Will the following commands produce exactly the same result ?
~~~{.bash}
$ guix package -m ~/default.scm
$ guix package -m ~/default.scm -p ~/.guix-profile
$ guix package -m ~/default.scm -p
/var/guix/profiles/per-user/fulbert/guix-profile
$ guix package -m ~/default.scm -p
/gnu/store/2sj11f64c9cgw40gkjy024vjl688zp7k-profile
~~~{end}
… and more generally, any guix command taking a `--profile` argument ?
Re: error: corrupt input while restoring archive from socket
Le Tue, Mar 09, 2021 at 08:48:25AM +0100, Fulbert a écrit : > For the past few days… maybe a couple of weeks (not sure when > it started exactly), I have had frequent errors with > substitutions. Those errors are not [always] reproducible as > another [or more] installation attempt succeed on the same [set of] > file[s]. For the past few `guix pull`… within a couple of days, I've been abble to upgrade guix and all my profiles with no errors. Whatever caused it seems to be fixed ! Thanks to the unknown working in the shadows ;)
guix configuration problem : bootloader "menu-entry"
Hello Guixers !
I am adding some `menu-entries` to my bootloader-configuration.
>From `$ info "(guix)Bootloader Configuration"`
‘device’ (default: ‘#f’)
The device where the kernel and initrd are to be found—i.e.,
for GRUB, “root” for this menu entry (*note (grub)root::).
This may be a file system label (a string), a file system UUID
(a bytevector, *note File Systems::), or ‘#f’, in which case
the bootloader will search the device containing the file
specified by the ‘linux’ field (*note (grub)search::). It
must _not_ be an OS device name such as ‘/dev/sda1’.
My problem is that `device` (or no device at all) does not seem to
work as expected. Whatever the `device`, guix produces an identical
`search --file…` grub menuentry.
Attached are 3 configuration test entries and their resulting
`menuentry` in grub.cfg. Not sure how to produce a "bytevector"
for the UUID though, but at least the test with a label (literal
string) should produce something like :
"search --label --set debian-stable"
Correct ? Or do I miss something ?!
Thanks for you time !
(menu-entries (list
(menu-entry
(label "TEST LABEL")
(device "debian-stable")
(linux "/boot/vmlinuz-4.19.0-14-amd64")
(linux-arguments '("root=UUID=2b5cc508-e2ea-4c43-a1c4-2532553af654 ro
quiet"))
(initrd "/boot/initrd.img-4.19.0-14-amd64"))
(menu-entry
(label "TEST UUID")
(device "2b5cc508-e2ea-4c43-a1c4-2532553af654")
(linux "/boot/vmlinuz-4.19.0-14-amd64")
(linux-arguments '("root=UUID=2b5cc508-e2ea-4c43-a1c4-2532553af654 ro
quiet"))
(initrd "/boot/initrd.img-4.19.0-14-amd64"))
(menu-entry
(label "TEST NO DEVICE")
(linux "/boot/vmlinuz-4.19.0-14-amd64")
(linux-arguments '("root=UUID=2b5cc508-e2ea-4c43-a1c4-2532553af654 ro
single"))
(initrd "/boot/initrd.img-4.19.0-14-amd64"
menuentry "TEST LABEL" {
search --file --set /boot/vmlinuz-4.19.0-14-amd64
linux /boot/vmlinuz-4.19.0-14-amd64
root=UUID=2b5cc508-e2ea-4c43-a1c4-2532553af654 ro quiet
initrd /boot/initrd.img-4.19.0-14-amd64
}
menuentry "TEST UUID" {
search --file --set /boot/vmlinuz-4.19.0-14-amd64
linux /boot/vmlinuz-4.19.0-14-amd64
root=UUID=2b5cc508-e2ea-4c43-a1c4-2532553af654 ro quiet
initrd /boot/initrd.img-4.19.0-14-amd64
}
menuentry "TEST NO DEVICE" {
search --file --set /boot/vmlinuz-4.19.0-14-amd64
linux /boot/vmlinuz-4.19.0-14-amd64
root=UUID=2b5cc508-e2ea-4c43-a1c4-2532553af654 ro single
initrd /boot/initrd.img-4.19.0-14-amd64
}
Re: error: corrupt input while restoring archive from socket
Le Thu, Mar 11, 2021 at 04:59:42PM +0300, Mikhail Kryshen a écrit : > Fulbert writes: > > > Hello Guixers, > > > > For the past few days… maybe a couple of weeks (not sure when > > it started exactly), I have had frequent errors with > > substitutions. Those errors are not [always] reproducible as > > another [or more] installation attempt succeed on the same [set of] > > file[s]. > > > > My computers (hardware/software) does not seem to be the > > cause as I have experienced the same problem on 2 PC's (not > > sharing the exact same guix configurations). > > > > Attached, 2 files with such an error. Note that I have > > translated the messages back to english (from french)… just in > > case you find some typos and wonder how guix could mistype… ^^ > > > > The error message common to all those recent failures is : > > error: corrupt input while restoring archive from socket > > I'm seeing this too, but only when guix tries to download from my own > local substitute server, which runs current guix-publish exposed > directly to the network without reverse proxy. Downloading from > ci.guix.gnu.org works without errors. Could this be a race condition > related to download rate? Hello and thanks for your time Mikhail, I only have a local channel with a couple of local files but no subtitute server. All downloads go through ci.gui.gnu.org. > Downloading from ci.guix.gnu.org works without errors. Could > this be a race condition related to download rate? I don't know. I'm not even sure what it means and how I could check that. Wouldn't this kind of problem be handled on the network "layers" ?… Because, as stated, I have not experienced other problems besides guix substitutions, whether guix related or any other use as a connected "desktop" user. > > > Any idea ? I have not found any recent similar issue on > > issues.guix.gnu.org. > > downloading from > > https://ci.guix.gnu.org/nar/gzip/qd16lz61f4gn20456h4ri0xb59dfh8kg-cmdliner-1.0.3.tbz... > > cmdliner-1.0.3.tbz 48KiB20.4MiB/s 00:00 [##] 100.0% > > > > Backtrace: > > In guix/ui.scm: > > 2164:12 19 (run-guix-command _ . _) > > In guix/scripts/substitute.scm: > > 633:2 18 (guix-substitute . _) > > In unknown file: > > 17 (with-continuation-barrier #) > > In ice-9/boot-9.scm: > > 1736:10 16 (with-exception-handler _ _ #:unwind? _ # _) > > In unknown file: > > 15 (apply-smob/0 #) > > In ice-9/boot-9.scm: > > 1736:10 14 (with-exception-handler _ _ #:unwind? _ # _) > > 1736:10 13 (with-exception-handler _ _ #:unwind? _ # _) > > 1731:15 12 (with-exception-handler # …) > > In guix/scripts/substitute.scm: > >682:17 11 (_) > > 391:7 10 (process-substitution _ "/gnu/store/p0xh0m6xkqfapgv7cy…" …) > > In ice-9/boot-9.scm: > > 1736:10 9 (with-exception-handler _ _ #:unwind? _ # _) > > In guix/scripts/substitute.scm: > > 400:9 8 (_) > > In ice-9/boot-9.scm: > > 1731:15 7 (with-exception-handler # …) > > 1669:16 6 (raise-exception _ #:continuable? _) > > 1667:16 5 (raise-exception _ #:continuable? _) > > 1669:16 4 (raise-exception _ #:continuable? _) > > 1764:13 3 (_ #< components: (#<> #<…>) > > 1669:16 2 (raise-exception _ #:continuable? _) > > 1667:16 1 (raise-exception _ #:continuable? _) > > 1669:16 0 (raise-exception _ #:continuable? _) > > > > ice-9/boot-9.scm:1669:16: In procedure raise-exception: > > Bad http-version header component: ¡_¨8á¯ñÿ > > > > Backtrace: > > In ice-9/boot-9.scm: > > 1736:10 4 (with-exception-handler _ _ #:unwind? _ # _) > > In unknown file: > >3 (apply-smob/0 #) > > In ice-9/boot-9.scm: > > 718:2 2 (call-with-prompt _ _ #) > > In ice-9/eval.scm: > > 619:8 1 (_ #(#(#))) > > In guix/ui.scm: > > 2164:12 0 (run-guix-command _ . _) > > > > guix/ui.scm:2164:12: In procedure run-guix-command: > > Bad http-version header component: ¡_¨8á¯ñÿ > > > > substitution of /gnu/store/p0xh0m6xkqfapgv7cy9012mjf2rx720r-cudf-0.9.tar.gz > > failed > > guix package: error: corrupt input while restoring archive from socket > > downloading from > > https://ci.guix.gnu.org/nar/lzip/wa2p58gv8fp81dglysnp2c9bffpdcwsr-ghc-blaze-markup-0.8.2.3... > > ghc-blaze-markup-0.8.2.3 124KiB > > 1.4MiB/s 00:00 [##] 100.0% > > > > Backtrace: > > In guix/ui.scm: > > 2
Re: error: corrupt input while restoring archive from socket
Le Tue, Mar 09, 2021 at 08:52:12AM +0100, divoplade a écrit : > Hello, Hello Divoplade and thanks for your help, > > Le mardi 09 mars 2021 à 08:48 +0100, Fulbert a écrit : > > > > Attached, 2 files with such an error. Note that I have > > translated the messages back to english (from french)… just in > > case you find some typos and wonder how guix could mistype… ^^ > You can run LANG=C guix ... to directly have the error messages in > english. Good tip. I knew and used it but, as I said, it is not reproducible so I would have to setup english as main language to catch all errors in english… and would miss bugs limited/related to french translations ;] > > > > The error message common to all those recent failures is : > > error: corrupt input while restoring archive from socket > > > > Any idea ? I have not found any recent similar issue on > > issues.guix.gnu.org. > I have had similar problems, you might want to run with --fallback (for > guix pull, guix package) to compile from source if the substitutes are > buggy. Good tip again and will use it when stuck on one substitute. Thank you. It's just that here, the problem does not realy seem to be buggy substitutes, as subsequent attempts would [generally] succeed. And if the transmissions over the network were to blame, I guess I would have other issues besides guix substitutes ?! So… I am curious as to what could cause this recent rise in guix substitue errors, and eventually, how to fix it. Thanks again for your time and help.
error: corrupt input while restoring archive from socket
Hello Guixers, For the past few days… maybe a couple of weeks (not sure when it started exactly), I have had frequent errors with substitutions. Those errors are not [always] reproducible as another [or more] installation attempt succeed on the same [set of] file[s]. My computers (hardware/software) does not seem to be the cause as I have experienced the same problem on 2 PC's (not sharing the exact same guix configurations). Attached, 2 files with such an error. Note that I have translated the messages back to english (from french)… just in case you find some typos and wonder how guix could mistype… ^^ The error message common to all those recent failures is : error: corrupt input while restoring archive from socket Any idea ? I have not found any recent similar issue on issues.guix.gnu.org. downloading from https://ci.guix.gnu.org/nar/gzip/qd16lz61f4gn20456h4ri0xb59dfh8kg-cmdliner-1.0.3.tbz... cmdliner-1.0.3.tbz 48KiB20.4MiB/s 00:00 [##] 100.0% Backtrace: In guix/ui.scm: 2164:12 19 (run-guix-command _ . _) In guix/scripts/substitute.scm: 633:2 18 (guix-substitute . _) In unknown file: 17 (with-continuation-barrier #) In ice-9/boot-9.scm: 1736:10 16 (with-exception-handler _ _ #:unwind? _ # _) In unknown file: 15 (apply-smob/0 #) In ice-9/boot-9.scm: 1736:10 14 (with-exception-handler _ _ #:unwind? _ # _) 1736:10 13 (with-exception-handler _ _ #:unwind? _ # _) 1731:15 12 (with-exception-handler # …) In guix/scripts/substitute.scm: 682:17 11 (_) 391:7 10 (process-substitution _ "/gnu/store/p0xh0m6xkqfapgv7cy…" …) In ice-9/boot-9.scm: 1736:10 9 (with-exception-handler _ _ #:unwind? _ # _) In guix/scripts/substitute.scm: 400:9 8 (_) In ice-9/boot-9.scm: 1731:15 7 (with-exception-handler # …) 1669:16 6 (raise-exception _ #:continuable? _) 1667:16 5 (raise-exception _ #:continuable? _) 1669:16 4 (raise-exception _ #:continuable? _) 1764:13 3 (_ #< components: (#<> #<…>) 1669:16 2 (raise-exception _ #:continuable? _) 1667:16 1 (raise-exception _ #:continuable? _) 1669:16 0 (raise-exception _ #:continuable? _) ice-9/boot-9.scm:1669:16: In procedure raise-exception: Bad http-version header component: ¡_¨8á¯ñÿ Backtrace: In ice-9/boot-9.scm: 1736:10 4 (with-exception-handler _ _ #:unwind? _ # _) In unknown file: 3 (apply-smob/0 #) In ice-9/boot-9.scm: 718:2 2 (call-with-prompt _ _ #) In ice-9/eval.scm: 619:8 1 (_ #(#(#))) In guix/ui.scm: 2164:12 0 (run-guix-command _ . _) guix/ui.scm:2164:12: In procedure run-guix-command: Bad http-version header component: ¡_¨8á¯ñÿ substitution of /gnu/store/p0xh0m6xkqfapgv7cy9012mjf2rx720r-cudf-0.9.tar.gz failed guix package: error: corrupt input while restoring archive from socket downloading from https://ci.guix.gnu.org/nar/lzip/wa2p58gv8fp81dglysnp2c9bffpdcwsr-ghc-blaze-markup-0.8.2.3... ghc-blaze-markup-0.8.2.3 124KiB 1.4MiB/s 00:00 [##] 100.0% Backtrace: In guix/ui.scm: 2164:12 19 (run-guix-command _ . _) In guix/scripts/substitute.scm: 633:2 18 (guix-substitute . _) In unknown file: 17 (with-continuation-barrier #) In ice-9/boot-9.scm: 1736:10 16 (with-exception-handler _ _ #:unwind? _ # _) In unknown file: 15 (apply-smob/0 #) In ice-9/boot-9.scm: 1736:10 14 (with-exception-handler _ _ #:unwind? _ # _) 1736:10 13 (with-exception-handler _ _ #:unwind? _ # _) 1731:15 12 (with-exception-handler # …) In guix/scripts/substitute.scm: 682:17 11 (_) 391:7 10 (process-substitution _ "/gnu/store/gs7l81p1xzgdzvxdjc…" …) In ice-9/boot-9.scm: 1736:10 9 (with-exception-handler _ _ #:unwind? _ # _) In guix/scripts/substitute.scm: 400:9 8 (_) In ice-9/boot-9.scm: 1731:15 7 (with-exception-handler # …) 1669:16 6 (raise-exception _ #:continuable? _) 1667:16 5 (raise-exception _ #:continuable? _) 1669:16 4 (raise-exception _ #:continuable? _) 1764:13 3 (_ #< components: (#<> #<…>) 1669:16 2 (raise-exception _ #:continuable? _) 1667:16 1 (raise-exception _ #:continuable? _) 1669:16 0 (raise-exception _ #:continuable? _) ice-9/boot-9.scm:1669:16: In procedure raise-exception: Bad Read-Header-Line header: # Backtrace: In ice-9/boot-9.scm: 1736:10 4 (with-exception-handler _ _ #:unwind? _ # _) In unknown file: 3 (apply-smob/0 #) In ice-9/boot-9.scm: 718:2 2 (call-with-prompt _ _ #) In ice-9/eval.scm: 619:8 1 (_ #(#(#))) In guix/ui.scm: 2164:12 0 (run-guix-command _ . _) guix/ui.scm:2164:12: In procedure run-guix-command: Bad Read-Header-Line header: # substitution of /gnu/store/gs7l81p1xzgdzvxdjcwfxqpfcwfdjbkv-ghc-clock-0.8 failed guix package: error: corrupt input while restoring archive from socket
Helvetica in `guix graph`
Hi Guixers, When I pipe `guix graph hello | xdot -`, the characters are displayed as squares. Got to insert `… | sed "s/Helvetica/sans/g" | …` in the pipeline. Not sure if this is a bug. Maybe my system should find a substitute for "Helvetica" automatically ? … or maybe line 241 of 'guix/graph.scm' needs a tiny correction ? (format port " \"~a\" [label = \"~a\", shape = box, fontname = Helvetica];~%" id label)) Best regards, Fulbert
Re: cleaning interrupted build "leftovers" ?
To Ricardo and Andreas : thank you very much for your help ! Best regards, Fulbert
cleaning interrupted build "leftovers" ?
Hello !
Yesterday, I interrupted (CTRL+C) the installation of
linux-libre@5.8.5 when it was in build phase (substitute not
available yet). Today, a new `guix system reconfigure` has
found a substitute. I am wondering if, in this situation, my system
has "leftovers" from the aborted build, that I would need to
clean… and if so, {where,how} to find it ?!
Based on the [attached] result of the following command, I
suppose, but I am unsure.
$ sudo find -L /var/guix /gnu/store -name "*linux-libre-5.8.5*" 2> /dev/null
Thanks for your time and best regards,
Fulbert
1228101 4 dr-xr-xr-x 6 root root 4096 jan 1 1970
/var/guix/profiles/system/kernel/share/doc/linux-libre-5.8.5
1228101 4 dr-xr-xr-x 6 root root 4096 jan 1 1970
/var/guix/profiles/system-8-link/kernel/share/doc/linux-libre-5.8.5
1228101 4 dr-xr-xr-x 6 root root 4096 jan 1 1970
/var/guix/gcroots/profiles/system/kernel/share/doc/linux-libre-5.8.5
1228101 4 dr-xr-xr-x 6 root root 4096 jan 1 1970
/var/guix/gcroots/profiles/system-8-link/kernel/share/doc/linux-libre-5.8.5
1228101 4 dr-xr-xr-x 6 root root 4096 jan 1 1970
/var/guix/gcroots/current-system/kernel/share/doc/linux-libre-5.8.5
1228101 4 dr-xr-xr-x 6 root root 4096 jan 1 1970
/gnu/store/.links/13sg3fqkvdk7gd19r93vkk8xa8wln6lvwl08vbwc7vaxsmrlw81f/share/doc/linux-libre-5.8.5
1223559 4 -r--r--r-- 2 root root 2414 jan 1 1970
/gnu/store/mggrn9zir4gdmqbs1rl4g97w2ff7qw4f-linux-libre-5.8.5-guix.tar.xz-builder
1223560 4 -r--r--r-- 2 root root 1928 jan 1 1970
/gnu/store/nycd1lx2pyld4m1w42h22cq0h550k82n-linux-libre-5.8.5-guix.tar.xz.drv
1223562 4 -r--r--r-- 2 root root 2872 jan 1 1970
/gnu/store/h74gb2a5v7yk5zbfqsjmig780j8zdbmr-linux-libre-5.8.5-guix.tar.xz-builder
1223563 4 -r--r--r-- 2 root root 1444 jan 1 1970
/gnu/store/aqz7p8v2wgs0f09ad00khdrifzmq03jh-linux-libre-5.8.5-guix.tar.xz.drv
1223564 8 -r--r--r-- 2 root root 6186 jan 1 1970
/gnu/store/asiwfzszdp91r0gl7mbxfjzmpnrg9nh6-linux-libre-5.8.5-guile-builder
1223565 4 -r--r--r-- 2 root root 3144 jan 1 1970
/gnu/store/b3lax3l19dr4m0bb49y4jd6m3xirk3hy-linux-libre-5.8.5.drv
1224195 0 -rw--- 1 root root0 aoû 27 23:44
/gnu/store/sqxpzb2flfhy3cana72bhv74rn7g32bd-linux-libre-5.8.5-guix.tar.xz.lock
1224897 4 dr-xr-xr-x 4 root root 4096 jan 1 1970
/gnu/store/b5rr113vjiykxr41s2yq7rn97sfh5dfw-linux-libre-5.8.5
1224967 4 dr-xr-xr-x 6 root root 4096 jan 1 1970
/gnu/store/b5rr113vjiykxr41s2yq7rn97sfh5dfw-linux-libre-5.8.5/share/doc/linux-libre-5.8.5
1227125 4 dr-xr-xr-x 6 root root 4096 jan 1 1970
/gnu/store/4hrv917g7vzw50qc6ak5dm15hrjc9rfv-linux-module-database/share/doc/linux-libre-5.8.5
1228101 4 dr-xr-xr-x 6 root root 4096 jan 1 1970
/gnu/store/wd31bgz7pcfvka6cr3lmdfwj0pc5p4pq-profile/share/doc/linux-libre-5.8.5
1228101 4 dr-xr-xr-x 6 root root 4096 jan 1 1970
/gnu/store/3vvmaf27da2i8659xb2v2mvrm8505f9n-system/kernel/share/doc/linux-libre-5.8.5
Re: nnn with icons
On Thu, Aug 20, 2020 at 11:21:30AM +, Ekaitz Zarraga wrote: > Hi, Hello Ekaitz > Is anyone here using nnn terminal file browser? I don't, but… > I installed but I don't see icons. Do you know what should I do to make the > icons work well with it? It says¹ "To see the icons correctly, install icons-in-terminal²." ¹ https://asciinema.org/a/353811 ² https://github.com/sebastiencs/icons-in-terminal > Thanks! You are welcome !
non-ascii char in mount-point name ?
Hi, In my Guix system configuration file, I have a (file-system … (mount-point "/mnt/raté")) with a 'é' (U+00E9) in its name, which gives the following error when trying to reconfigure : system: error: invalid character `�' in name `shepherd-file-system--mnt-raté.scm-builder' Did I miss something or is it a Guix limitation ?
Re: error setting console font in system.scm
On Sat, Jun 13, 2020 at 09:18:18PM -0700, John Soo wrote:
> Hello Fullbert,
>
> Fulbert writes:
>
> > Trying to change console font with the following in "services" section
> > of my system configuration file :
> >
> >
> > …
> > (services (append (list
> > …
> > (service console-font-service-type
> > `(("tty3" . ,(file-append font-terminus
> > "/share/consolefonts/ter-128n"
> > ) %desktop-services))
> > …
> >
> >
> > which results in the following error when reconfiguring the system :
> >
> >
> > $ sudo guix system --dry-run reconfigure /etc/config.scm
> > guix system: error: service 'console-font-tty3' provided more than once
> >
>
> This is because there is already a console-font-service-type in
> %desktop-services. […]You will need to modify the existing service instead
> like below. Note I have not tested this myself but something like it can be
> found in the documentation of guile association lists
>
> https://www.gnu.org/software/guile/manual/html_node/Adding-or-Setting-Alist-Entries.html
>
> ;; At the top of the file
> (use-modules
> ...
> (ice-9 match))
>
> ;; Replace %desktop-services with this:
>
> (modify-services %desktop-services
> (console-font-service-type
> configuration =>
> (map
> (match-lambda
> (("tty3" . f)
> `("tty3" . (file-append font-terminus
> "/share/consolefonts/ter-128n")))
> ((tty . font) `(,tty . ,font)))
> configuration)))
>
> > I probably missunderstand something and/or ill-format the
> > configuration…?… Help appreciated.
>
> No problem. The error message is saying that such a service would
> conflict with the existing one. The aim of the snippet is to keep the
> other tty fonts and update the one on tty3.
>
> Hope that helps!
Indeed! It works now. Thank you for your Help John !
For this to work though, I just had to correct a typo : add a `comma`
(to _unquote_, if I'm not wrong) before the `(file-append …`.
So, for reference :
;; At the top of the file
(use-modules
...
(ice-9 match))
;; Replace %desktop-services with this:
(modify-services %desktop-services
(console-font-service-type configuration =>
(map
(match-lambda
(("tty3" . f)
`("tty3" . ,(file-append
font-terminus
"/share/consolefonts/ter-128n.psf.gz")))
((tty . font) `(,tty . ,font))) configuration)))
error setting console font in system.scm
Hi Guixers,
(define myself (guix-noob-user (not (programmer
Trying to change console font with the following in "services" section
of my system configuration file :
…
(services (append (list
…
(service console-font-service-type
`(("tty3" . ,(file-append font-terminus
"/share/consolefonts/ter-128n"
) %desktop-services))
…
which results in the following error when reconfiguring the system :
$ sudo guix system --dry-run reconfigure /etc/config.scm
guix system: error: service 'console-font-tty3' provided more than once
I probably missunderstand something and/or ill-format the
configuration…?… Help appreciated.
Below is the related [(guix) Base services] Texinfo section.
--scheme Variable: console-font-service-type
Install the given fonts on the specified ttys (fonts are per
virtual console on the kernel Linux). The value of this service is
a list of tty/font pairs. The font can be the name of a font
provided by the ‘kbd’ package or any valid argument to ‘setfont’,
as in this example:
`(("tty1" . "LatGrkCyr-8x16")
("tty2" . ,(file-append
font-tamzen
"/share/kbd/consolefonts/TamzenForPowerline10x20.psf"))
("tty3" . ,(file-append
font-terminus
"/share/consolefonts/ter-132n"))) ; for HDPI
error setting console font in system.scm
Hi Guixers,
(define myself (guix-noob-user (not (programmer
Trying to change console font with the following in "services" section
of my system configuration file :
…
(services (append (list
…
(service console-font-service-type
`(("tty3" . ,(file-append font-terminus
"/share/consolefonts/ter-128n"
) %desktop-services))
…
which results in the following error when reconfiguring the system :
$ sudo guix system --dry-run reconfigure /etc/config.scm
guix system: error: service 'console-font-tty3' provided more than once
I probably missunderstand something and/or ill-format the
configuration…?… Help appreciated.
Below is the related [(guix) Base services] Texinfo section.
--scheme Variable: console-font-service-type
Install the given fonts on the specified ttys (fonts are per
virtual console on the kernel Linux). The value of this service is
a list of tty/font pairs. The font can be the name of a font
provided by the ‘kbd’ package or any valid argument to ‘setfont’,
as in this example:
`(("tty1" . "LatGrkCyr-8x16")
("tty2" . ,(file-append
font-tamzen
"/share/kbd/consolefonts/TamzenForPowerline10x20.psf"))
("tty3" . ,(file-append
font-terminus
"/share/consolefonts/ter-132n"))) ; for HDPI
Hi Guixers,
(define myself (guix-noob-user (not (programmer
Trying to change console font with the following in "services" section of my sys
tem configuration file :
…
(services (append (list
…
(service console-font-service-type
`(("tty3" . ,(file-append font-terminus "/share/consolefonts/ter-128n"
) %desktop-services))
…
which results in the following error when reconfiguring the system :
$ sudo guix system --dry-run reconfigure /etc/config.scm
guix system: error: service 'console-font-tty3' provided more than once
I probably missunderstand something and/or ill-format the configuration…?
Below is the related [(guix) Base services] Texinfo section.
--scheme Variable: console-font-service-type
Install the given fonts on the specified ttys (fonts are per
virtual console on the kernel Linux). The value of this service is
a list of tty/font pairs. The font can be the name of a font
provided by the ‘kbd’ package or any valid argument to ‘setfont’,
as in this example:
`(("tty1" . "LatGrkCyr-8x16")
("tty2" . ,(file-append
font-tamzen
"/share/kbd/consolefonts/TamzenForPowerline10x20.psf"))
("tty3" . ,(file-append
font-terminus
"/share/consolefonts/ter-132n"))) ; for HDPI
__
Last updated 2020-06-13 12:52:15 CEST
