Re: authenticating git checkouts
Simon Josefsson via writes: > jas@kaka:~/src/libntlm$ guix git authenticate > guix git: successfully authenticated commit > a94c085b17dd72904d8913411e1e85477e12 > jas@kaka:~/src/libntlm$ git commit -m"maint: Mention guix git introductory > commit." README.md > [master 4f64fd9] maint: Mention guix git introductory commit. > 1 file changed, 8 insertions(+) > jas@kaka:~/src/libntlm$ guix git authenticate > Authenticating commits a94cfff to 4f64fd9 (1 new commits)... > ▕██▏guix > git: fel: commit 4f64fd94d5e11b0f9226a3e15cae69ef9fdbb585 not signed by an > authorized key: A3CC 9C87 0B9D 310A BAD4 CF2F 5172 2B08 FE47 45A2 > jas@kaka:~/src/libntlm$ I forgot to show git log output here, proving that this git commit was actually signed: see below. I suspect there is some primary vs subkey confusion, but maybe it could be some parsing issue? I'm using guix on Trisquel 11 with fairly old gpg and git. jas@kaka:~/src/libntlm$ git log -1 --show-signature commit 4f64fd94d5e11b0f9226a3e15cae69ef9fdbb585 (HEAD -> master) gpg: Signatur gjord tor 9 maj 2024 10:49:27 CEST gpg: med EDDSA-nyckeln A3CC9C870B9D310ABAD4CF2F51722B08FE4745A2 gpg: Korrekt signatur från "Simon Josefsson " [förbehållslös] Author: Simon Josefsson Date: Thu May 9 10:49:27 2024 +0200 maint: Mention guix git introductory commit. jas@kaka:~/src/libntlm$ /Simon signature.asc Description: PGP signature
authenticating git checkouts
Hi I read https://guix.gnu.org/blog/2024/authenticate-your-git-checkouts/ and wondered why I hadn't tried that long ago, but better late than never, and thanks for writing this blog post to nudge us in the right direction! I tried to adopt this approach for the libntlm project, but failed. Chronological list of first impression thoughts I had: x) How about introducing an enforcable file-name convention for the key filenames? While using human readable names like 'alice.key' looks nice, it isn't possible to look at content of the filename and determine what the filename should be. The filename doesn't appear to convey any important information, so I think it would be better to have it be reproducible. You could use some transliteration of the e-mail address, but I think there are corner cases here. So how about merely using the primary PGP fingerprint value? For me it would be B1D2BD1375BECB784CF4F8C4D73CF638C53C06BE.key assuming PGP fingerprints are specified as case sensitive. x) How about using ASCII armored PGP blobs instead of binary PGP files for the *.key files? While storing binary files in git mostly work these days, I ran into a CRLF-related problem for a small binary file in git on Windows lately, so it still seems to happen sometimes. I tried this, but it seems 'guix git authenticate' doesn't cope with ASCII armored PGP keys: Backtrace: 12 (primitive-load "/home/jas/.config/guix/current/bin/guix") In guix/ui.scm: 2312:7 11 (run-guix . _) 2275:10 10 (run-guix-command _ . _) In ice-9/boot-9.scm: 1752:10 9 (with-exception-handler _ _ #:unwind? _ # _) 1752:10 8 (with-exception-handler _ _ #:unwind? _ # _) 1747:15 7 (with-exception-handler # …) In guix/scripts/git/authenticate.scm: 309:10 6 (_) In guix/git-authenticate.scm: 403:4 5 (authenticate-repository # _ # # …) In srfi/srfi-1.scm: 460:18 4 (fold # …) In guix/git-authenticate.scm: 255:29 3 (_ _ #< ids: # fingerprints:…>) In unknown file: 2 (open-bytevector-input-port #f #) In ice-9/boot-9.scm: 1685:16 1 (raise-exception _ #:continuable? _) 1685:16 0 (raise-exception _ #:continuable? _) ice-9/boot-9.scm:1685:16: In procedure raise-exception: In procedure open-bytevector-input-port: Wrong type argument in position 1 (expecting bytevector): #f x) How about exporting minimal keys rather than keys with a bunch of signatures on? This makes the key files a bit more reproducible. The downside is that it kills the web-of-trust key authentication process, so maybe actually recommend NOT using minimal keys? I'm mixed on this, and this probably needs more discussion. Maybe minimizing the keys are more GDPR-compliant :-) Doing so also reduces size: jas@kaka:~/src/libntlm$ gpg --export si...@josefsson.org > jas.key jas@kaka:~/src/libntlm$ ls -la jas.key -rw-rw-r-- 1 jas jas 105243 maj 9 10:28 jas.key jas@kaka:~/src/libntlm$ gpg --export-options export-minimal --export si...@josefsson.org > jas.key jas@kaka:~/src/libntlm$ ls -la jas.key -rw-rw-r-- 1 jas jas 3534 maj 9 10:28 jas.key jas@kaka:~/src/libntlm$ x) How about support of non-PGP formats? You could put PGP keys in a sub-directory pgp/foo.key and allow for future expansion as ssh/bar.key or x509/baz.key etc. x) The 'name' field in .guix-authenticate doesn't seem to be necessary at all? Maybe not even suggest including it. x) While using s-exp's for .guix-authenticate are fine, I don't think this will go down well with the git crowd. How about a yet another YAML format a'la git? Let's call it ~/.gitauthenticate: gpg-introduction-commit = a94c085b17dd72904d8913411e1e85477e12 gpg-introduction-keyid = "B1D2 BD13 75BE CB78 4CF4 F8C4 D73C F638 C53C 06BE" gpg-keyring-branch = gpg-keyring This could be extended for ssh and x509 too: ssh-introduction-commit = a94c085b17dd72904d8913411e1e85477e12 ssh-introduction-keyfile = "ssh-ed25519 C3NzaC1lZDI1NTE5ILzCFcHHrKzVSPDDarZPYqn89H5TPaxwcORgRg+4DagE cardno:FFFE42315277" ssh-keyring-branch = ssh-keyring x509-introduction-commit = a94c085b17dd72904d8913411e1e85477e12 x509-introduction-keyfile = 0xA7C7D7A7 x509-keyring-branch = x509-keyring and $someone can write a new tool 'git-authenticate'. x) Running this command: guix git authenticate 2e6e8027c75942450a0e4ae0f58e876715782cae "B1D2 BD13 75BE CB78 4CF4 F8C4 D73C F638 C53C 06BE" sets up .git/config properly, but running it again with a different git commit does not alter .git/config, which was a bit unexpected. Is this intentional? The second invocation exit fine but running 'guix git authenticate' again failed. Removing the configuration from .git/config and re-running both commands made it work, but this feels a bit unsafe. 5) The implementation seems confused by PGP subkeys. Verifying the initial commit after adding .guix-authenticate works fine: jas@kaka:~/src/libntlm$ git log -1 -p commit 2e6e8027c75942450a0e4ae0f58e876715782cae (HEAD -> master) Author: Simon Josefsson Date: Thu Ma
Re: glibc-utf8-locales
tis 2022-03-08 klockan 10:28 + skrev Tobias Geerinckx-Rice:
> Hullo Simon,
>
> Simon Josefsson via wrote:
> > First, I wonder if this is optimal. There must be many machines
> > (servers and embedded) where having all locales installed on is
> > wasteful, but where it is useful to have the C.UTF-8 and/or
> > en_US.UTF-8
> > installed, to get minimal working UTF-8 support. Making this hard
> > to
> > achieve for users seems unhelpful to me. I understand the
> > motivation
> > for the patch
>
> I don't think you do, if that's what you thought it was ;-)
Sorry I was unclear -- I reckon the motivation for the patch was that
the semantics with the old glibc-utf8-locales package was confusing
(not containing all UTF-8 locales). Still, I think the old package did
provide some useful aspect which is now lost, and has to be worked
around with more complex logic. Offering a newer more simple solution
is what I'm asking for. Meanwhile I'm happy to use the more complex
solution that you helped me with (below).
> > (append (map specification->package
> > '("glibc-useful-swedish-utf8-locales"
>
> You have a (probably left-over) specification->package call but no
> "glibc-useful-swedish-utf8-locales" package in Guix for it to find.
> It does not search the environment.
>
> Remove the spec and refer to your custom variable directly, e.g.:
>
> (packages (append (list glibc-useful-swedish-utf8-locales ...)
> ...))
Thanks, I managed to get it to work now:
https://gitlab.com/jas/sjd-cosmos/-/blob/master/hamster.josefsson.org/overlay/etc/config.scm
https://gitlab.com/jas/sjd-cosmos/-/commit/cecbdf4ad834c3d06e1344d843582ac1defa935b
However, I'm not sure it is fully working, 'locale -a' gives me more
than just the locales I specified?! Yes I did successful 'system
reconfigure' and reboot into new system.
/Simon
root@hamster ~# /gnu/store/2fk1gz2s7ppdicynscra9b19byrrr866-glibc-
2.33/bin/locale -a
C
ca_ES.utf8
cs_CZ.utf8
da_DK.utf8
de_DE.utf8
el_GR.utf8
en_AU.utf8
en_CA.utf8
en_GB.utf8
en_US.utf8
en_US.UTF-8
es_AR.utf8
es_CL.utf8
es_ES.utf8
es_MX.utf8
fi_FI.utf8
fr_BE.utf8
fr_CA.utf8
fr_CH.utf8
fr_FR.utf8
ga_IE.utf8
it_IT.utf8
ja_JP.utf8
ko_KR.utf8
nb_NO.utf8
nl_NL.utf8
pl_PL.utf8
POSIX
pt_PT.utf8
ro_RO.utf8
ru_RU.utf8
sv_SE.utf8
tr_TR.utf8
uk_UA.utf8
vi_VN.utf8
zh_CN.utf8
root@hamster ~#
signature.asc
Description: This is a digitally signed message part
glibc-utf8-locales
Hi. Reconfiguring my machine lately fails with:
root@hamster ~# guix system reconfigure /etc/config.scm
guix system: error: glibc-utf8-locales: unknown package
guix system: error: failed to load '/etc/config.scm':
srfi/srfi-1.scm:586:17: In procedure map1:
Throw to key `quit' with args `(1)'.
root@hamster ~#
I noticed the following commmit:
https://lists.gnu.org/archive/html/guix-commits/2022-02/msg01204.html
First, I wonder if this is optimal. There must be many machines
(servers and embedded) where having all locales installed on is
wasteful, but where it is useful to have the C.UTF-8 and/or en_US.UTF-8
installed, to get minimal working UTF-8 support. Making this hard to
achieve for users seems unhelpful to me. I understand the motivation
for the patch, so I don't think it is necessarily wrong, just that
something more would also be useful. Maybe it is just the documentation
part that could be improved).
Trying to follow its advice, I modified my config.scm [1] as follows:
(use-modules (gnu packages base)) ; make-glibc-utf8-locales
...
(define my-glibc-locales
(make-glibc-utf8-locales
glibc
#:locales (list "en_US" "sv_SE")
#:name "glibc-useful-swedish-utf8-locales"))
...
(operating-system
...
(packages (append (map specification->package
'("glibc-useful-swedish-utf8-locales"
...
Thus letting "glibc-useful-swedish-utf8-locales" replace my earlier use
of "glibc-utf8-locales" in that package list stanza (which worked
happily for me for a long time). However it results in the following
error:
root@hamster ~# guix system reconfigure /etc/config.scm
guix system: error: glibc-useful-swedish-utf8-locales: unknown package
guix system: error: failed to load '/etc/config.scm':
srfi/srfi-1.scm:586:17: In procedure map1:
Throw to key `quit' with args `(1)'.
root@hamster ~#
I tried changing the definition into:
(define glibc-useful-swedish-utf8-locales
(make-glibc-utf8-locales
glibc
#:locales (list "en_US" "sv_SE")
#:name "glibc-useful-swedish-utf8-locales"))
and even trying
(make-glibc-utf8-locales
glibc
#:locales (list "en_US" "sv_SE")
#:name "glibc-useful-swedish-utf8-locales")
to prove that I'm clearly not understanding what I'm doing, however, it
still doesn't work.
Help?
/Simon
[1]
https://gitlab.com/jas/sjd-cosmos/-/blob/master/hamster.josefsson.org/overlay/etc/config.scm
signature.asc
Description: PGP signature
Re: 'guix reconfigure' fail to build 'rsnapshot'
br...@waegenei.re writes: > First we go back to our failing build² and have a look in its log⁷. At the > end of it there is 2 failing tests t/backup_exec/backup_exec.t and > t/cmd-post_pre-exec/cmd-post_pre-exec.t. That's what we need to repair or > disable. Now we need to build it locally and inspect it more in depth, we > do that with “guix build rsnapshot --keep-failed --no-offload” and > obviously it fail as expected and guix guide us to the build directory > “/tmp/guix-build-rsnapshot-1.4.4.drv-1”. > > To find out why thoses 2 tests ae failing we are gonna run them manually. > We change directory to > “/tmp/guix-build-rsnapshot-1.4.4.drv-0/rsnapshot-1.4.4” the failed build > and find the build “rsnapshot“ program in it but it's not executable, so we > make it so “chmod +x rsnapshot”. Then we inspect the build tests Hi Brice. May thanks for this excellent walk-through, I followed the steps locally here to learn, hoping my next problem follows the same pattern. /Simon signature.asc Description: PGP signature
'guix reconfigure' fail to build 'rsnapshot'
Hi! Since some time, 'guix reconfigure' on my machine fails: building /gnu/store/chilbs792mqssmi726zmvff5zg49gija-provenance.drv... building /gnu/store/9skvgwsl0vxccv5sbgvqimkhk3938v8y-rsnapshot-1.4.4.drv... \ 'check' phasebuilder for `/gnu/store/9skvgwsl0vxccv5sbgvqimkhk3938v8y-rsnapshot-1.4.4.drv' failed with exit code 1 build of /gnu/store/9skvgwsl0vxccv5sbgvqimkhk3938v8y-rsnapshot-1.4.4.drv failed View build log at '/var/log/guix/drvs/9s/kvgwsl0vxccv5sbgvqimkhk3938v8y-rsnapshot-1.4.4.drv.bz2'. cannot build derivation `/gnu/store/a9kw0xkbx6wy0w893b4kzzrxh3a5lnx6-profile.drv': 1 dependencies couldn't be built building /gnu/store/89hsi8xglfybbvrjrqf0zhkg546ahjyd-shepherd-console-font-tty1.scm.drv... cannot build derivation `/gnu/store/mx5zqmx388ixzr55rzak59wfygpyn6fm-system.drv': 1 dependencies couldn't be built guix system: error: build of `/gnu/store/mx5zqmx388ixzr55rzak59wfygpyn6fm-system.drv' failed root@hamster ~# bzcat /var/log/guix/drvs/9s/kvgwsl0vxccv5sbgvqimkhk3938v8y-rsnapshot-1.4.4.drv.bz2|tail Failed test: 1 Non-zero exit status: 1 t/cmd-post_pre-exec/cmd-post_pre-exec.t (Wstat: 256 Tests: 4 Failed: 1) Failed test: 4 Non-zero exit status: 1 Files=12, Tests=38, 3 wallclock secs ( 0.04 usr 0.01 sys + 1.51 cusr 0.23 csys = 1.79 CPU) Result: FAIL Failed 2/12 test programs. 2/38 subtests failed. make: *** [Makefile:938: test] Error 255 command "make" "test" failed with status 2 root@hamster ~# How can I fix this? Is this something unique on my machine, or does it indicate a bug in the packaging of 'rsnapshot'? I'm not sure how to proceed with debugging. How come others haven't noticed this, aren't all packages built centrally to make sure things build? Thanks, /Simon signature.asc Description: PGP signature
Re: guix pull: error: corrupt input while restoring archive
Andreas Enge writes: >> I am still curious what happened before, in case the previous error >> appears again. > > Other people have experienced the same problem; apparently it was a bug > that has been fixed in the meantime. So as "guix pull" finally succeeded, > you should not see it again. Okay, thanks for confirming that! I hope it won't occur again. /Simon signature.asc Description: PGP signature
Re: guix pull: error: corrupt input while restoring archive
Simon Josefsson via writes: > Hi. I have a machine that have been running Guix for a couple of years > and since November I rely on unattended-upgrades to keep it updated. I > have stopped doing manual upgrades but may have done it on reflex a > couple of times since November. Now when I run 'guix pull' the errors > below are shown. What does it mean? How do I recover? > > I'm attaching the two last unattended-upgrades logs since there are a > couple of weird errors in it too -- it is hard to tell when things > happened since timestamps are lacking though. Minutes after posting the above, 'guix pull' works again after having been broken in the above way for at least a week. I never realized that asking for help on this list would solve things this quickly! See successful output below. I am still curious what happened before, in case the previous error appears again. Sorry for double-posting the last mail, as well... /Simon root@hamster ~# guix pull Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'... Authenticating channel 'guix', commits 9edb3f6 to f27bdad (3 new commits)... Building from this channel: guix https://git.savannah.gnu.org/git/guix.git f27bdad substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% building /gnu/store/k41lba5y0dgfmniwpbsyrk53wrbpswka-compute-guix-derivation.drv... Computing Guix derivation for 'x86_64-linux'... / substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% The following derivations will be built: /gnu/store/0hc2hg9p8k3001118r90rhygljb1iyp7-profile.drv /gnu/store/hyrb6bnhlag79zzrn4zhlw8aw6myka44-guix-f27bdad0a.drv /gnu/store/99gb0xp8kzl1ia834hwaphacxdfcgbky-guix-daemon.drv /gnu/store/y6p93hwy4xi36c6bdkjl41g8fgc70ynw-guix-command.drv /gnu/store/w1r6mslxiymilxx09mi7wqkj6i4gz8x1-guix-module-union.drv /gnu/store/riy6v8ljn38qz9cixhrrxj2af6dwws3z-guix-f27bdad0a-modules.drv /gnu/store/1087m6fp2im91791sg0l692f9qqzd944-guix-packages-base-modules.drv /gnu/store/29wq3lkkxgnlzsl4npf0ipjzj3h65vxy-guix-core-modules.drv /gnu/store/ghg84r9nxvg044msw5yyg3ayya173yac-guix-core-source.drv /gnu/store/cp423il69slzys5gk0ccf3ry9xvqj2x4-guix-system-tests-modules.drv /gnu/store/g4iv8am51dx3rw0kdiz8w86gcqhzwp5a-guix-packages-modules.drv /gnu/store/gwbyqrz5lrq4ifiil86jy6ch8ixjs1sr-guix-system-modules.drv /gnu/store/i5p14ialmzxsvf94nizf20kffdn986cz-guix-extra-modules.drv /gnu/store/pnzwjmcn4b3sqnljy49bhz45061kzlkl-guix-cli-modules.drv /gnu/store/qh1im2zg8jc1pb0bcy8csg8ipwvqr78x-guix-config-modules.drv /gnu/store/a8f3c0vznn7xsk2rzjchys6wg3137m60-guix-config.drv /gnu/store/l04sj05jiwhb4h2aimg88pcgg9kj30gp-guix-config-source.drv /gnu/store/illv3px23d8q9c6lm8vsc2axym21yjw4-config.scm.drv /gnu/store/3w6pj5cw0r2vg0zjhji48hym5p6p6wlq-inferior-script.scm.drv /gnu/store/vaila554g2c5m3llhmi68gc5qj7avdva-profile.drv 23.7 MB will be downloaded downloading from https://ci.guix.gnu.org/nar/lzip/nyk4hk10b11hzkyrxz5l90mf6np722i8-guix-cli ... guix-cli 797KiB 1.5MiB/s 00:01 [##] 100.0% downloading from https://ci.guix.gnu.org/nar/lzip/2fgnna336vdifcl4k41l0sq66v8qf6r4-guix-packages ... guix-packages 3.0MiB1.8MiB/s 00:02 [##] 100.0% downloading from https://ci.guix.gnu.org/nar/lzip/lg72byprv78pgjai9j48m4ffvim2xb5y-guix-packages-base ... guix-packages-base 9.5MiB 3.1MiB/s 00:03 [##] 100.0% downloading from https://ci.guix.gnu.org/nar/lzip/vc4l97d8ivf520c7vj16hx8vc5q75pkc-guix-system ... guix-system 5.5MiB 4.2MiB/s 00:01 [##] 100.0% downloading from https://ci.guix.gnu.org/nar/lzip/cdsm6mqpfhk7y8sks05vf0vkpi9x4qh2-guix-system-tests ... guix-system-tests 299KiB1.4MiB/s 00:00 [##] 100.0% downloading from https://ci.guix.gnu.org/nar/lzip/4gffr26pb2zpasncanbp2ibamg1c5ms6-openssl-1.1.1k ... openssl-1.1.1k 2.1MiB 1.2MiB/s 00:02 [##] 100.0% downloading from https://ci.guix.gnu.org/nar/lzip/g9gf1ndxryjc15mrjiy41w162lx8j6cv-sqlite-3.32.3 ... sqlite-3.32.3 1014KiB 3.8MiB/s 00:00 [##] 100.0% downloading from https://ci.guix.gnu.org/nar/lzip/86ffkihfqdmvnmkq0aq57lwkb5z22nsj-zstd-1.4.4-lib ... zstd-1.4.4-lib 345KiB 3.0MiB/s 00:00 [##] 100.0% building /gnu/store/illv3px23d8q9c6lm8vsc2axym21yjw4-config.scm.drv... applying 1 graft for /gnu/store/jx6z9mfy88zl8sk3n9id4sxaghwkzjhl-guile-sqlite3-0.1.2.drv ... applying 1 graft for /gnu/store/3mnldv1whgj081j9lk97whsjapzfnis5-guile-zstd-0.1.1.drv ... building /gnu/store/pnzwjmcn4b3sqnljy49bhz45061kzlkl-guix-cli-modules.drv... building /gnu/store/l04sj05jiwhb4h2aimg88pcgg9kj30gp-guix-config-source.drv... building /gnu/store/ghg84r9nxvg04
guix pull: error: corrupt input while restoring archive
Hi. I have a machine that have been running Guix for a couple of years
and since November I rely on unattended-upgrades to keep it updated. I
have stopped doing manual upgrades but may have done it on reflex a
couple of times since November. Now when I run 'guix pull' the errors
below are shown. What does it mean? How do I recover?
I'm attaching the two last unattended-upgrades logs since there are a
couple of weird errors in it too -- it is hard to tell when things
happened since timestamps are lacking though.
Thanks,
/Simon
root@hamster ~# guix pull
Updating channel 'guix' from Git repository at
'https://git.savannah.gnu.org/git/guix.git'...
Building from this channel:
guix https://git.savannah.gnu.org/git/guix.git 0374617
Computing Guix derivation for 'x86_64-linux'... /
The following derivations will be built:
/gnu/store/m1qdzyhl3r3979w9bgpxprw2fqrpxzfb-profile.drv
/gnu/store/2vq93a23y7dp615hprh00jif9r0b4cxw-guix-037461792.drv
/gnu/store/0q7942g24c3yd48wb93y942kmj6s3hvp-guix-command.drv
/gnu/store/8ia9xvwz2aqfxk94crmndasnk9px366a-guix-module-union.drv
/gnu/store/1xhgz2qgiwf2x0v8ffy1lh4syzl7cj2d-guix-037461792-modules.drv
/gnu/store/1n04rgahyalbdbj852wjz5w9jr7p83jm-guix-system-modules.drv
/gnu/store/29wq3lkkxgnlzsl4npf0ipjzj3h65vxy-guix-core-modules.drv
/gnu/store/ghg84r9nxvg044msw5yyg3ayya173yac-guix-core-source.drv
/gnu/store/4fqbng9f9rqysik073xk7narifnadbw2-guix-packages-base-modules.drv
/gnu/store/gxm22830afsym9h246axyn01wlg4p6d1-guix-config-modules.drv
/gnu/store/3ij0jpi5ryhlj3jgdn1xsrac8v2khbg7-guix-config-source.drv
/gnu/store/cxmrhhgl9q2habbsgv6b3f7sjqy02pbc-config.scm.drv
/gnu/store/brcrh5dnbhqi04abh78r0qhza63ph470-guix-config.drv
/gnu/store/i5p14ialmzxsvf94nizf20kffdn986cz-guix-extra-modules.drv
/gnu/store/j5ni6cjgb55ri3qa2f7b8xpviy0jgkjr-guix-cli-modules.drv
/gnu/store/jj6hfbqfxjnvbsvz3g328png3nwsyxf6-guix-packages-modules.drv
/gnu/store/ww1jqx2wk19wbg342fin9k6p4qm6hv3i-guix-system-tests-modules.drv
/gnu/store/vd77mjsik676fqca9l23ljxgavxj5x4r-guix-daemon.drv
/gnu/store/a673nzfw8pdppwrb6m7xj0631qsb9z7k-profile.drv
/gnu/store/kbn57bk7ghw3qi8hk00gjyn5r2rdl3j1-inferior-script.scm.drv
19.7 MB will be downloaded
downloading from
https://ci.guix.gnu.org/nar/lzip/znswpawdi6wdd7a2jlh53ya7fscp5322-guix-packages-base
...
guix-packages-base 9.5MiB
3.1MiB/s 00:03 [##] 100.0%
downloading from
https://ci.guix.gnu.org/nar/lzip/9ba9smischbqpl5a12nfipcwwkb6bl1f-guix-system
...
guix-system
3.8MiB/s 00:02 | 7.1MiB transferred
Backtrace:
In guix/ui.scm:
2164:12 19 (run-guix-command _ . _)
In guix/scripts/substitute.scm:
652: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:
701:17 11 (_)
410:7 10 (process-substitution _ "/gnu/store/nvx8kkadjl81k5h544…" …)
In ice-9/boot-9.scm:
1736:10 9 (with-exception-handler _ _ #:unwind? _ # _)
In guix/scripts/substitute.scm:
419: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 (_ #<&compound-exception components: (#<&error> #<&irri…>)
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:
Throw to key `bad-response' with args `("Bad Response-Line: ~s" (""))'.
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:
Throw to key `bad-response' with args `("Bad Response-Line: ~s" (""))'.
substitution of /gnu/store/nvx8kkadjl81k5h544y4kahz6jlzqqyl-guix-system-tests
failed
guix pull: error: corrupt input while restoring archive from #
root@hamster ~#
unattended-upgrade-logs.tar.bz2
Description: Binary data
signature.asc
Description: PGP signature
guix pull: error: corrupt input while restoring archive
Hi. I have a machine that have been running Guix for a couple of years
and since November I rely on unattended-upgrades to keep it updated. I
have stopped doing manual upgrades but may have done it on reflex a
couple of times since November. Now when I run 'guix pull' the errors
below are shown. What does it mean? How do I recover?
I'm attaching the two last unattended-upgrades logs since there are a
couple of weird errors in it too -- it is hard to tell when things
happened since timestamps are lacking though.
Thanks,
/Simon
root@hamster ~# guix pull
Updating channel 'guix' from Git repository at
'https://git.savannah.gnu.org/git/guix.git'...
Building from this channel:
guix https://git.savannah.gnu.org/git/guix.git 0374617
Computing Guix derivation for 'x86_64-linux'... /
The following derivations will be built:
/gnu/store/m1qdzyhl3r3979w9bgpxprw2fqrpxzfb-profile.drv
/gnu/store/2vq93a23y7dp615hprh00jif9r0b4cxw-guix-037461792.drv
/gnu/store/0q7942g24c3yd48wb93y942kmj6s3hvp-guix-command.drv
/gnu/store/8ia9xvwz2aqfxk94crmndasnk9px366a-guix-module-union.drv
/gnu/store/1xhgz2qgiwf2x0v8ffy1lh4syzl7cj2d-guix-037461792-modules.drv
/gnu/store/1n04rgahyalbdbj852wjz5w9jr7p83jm-guix-system-modules.drv
/gnu/store/29wq3lkkxgnlzsl4npf0ipjzj3h65vxy-guix-core-modules.drv
/gnu/store/ghg84r9nxvg044msw5yyg3ayya173yac-guix-core-source.drv
/gnu/store/4fqbng9f9rqysik073xk7narifnadbw2-guix-packages-base-modules.drv
/gnu/store/gxm22830afsym9h246axyn01wlg4p6d1-guix-config-modules.drv
/gnu/store/3ij0jpi5ryhlj3jgdn1xsrac8v2khbg7-guix-config-source.drv
/gnu/store/cxmrhhgl9q2habbsgv6b3f7sjqy02pbc-config.scm.drv
/gnu/store/brcrh5dnbhqi04abh78r0qhza63ph470-guix-config.drv
/gnu/store/i5p14ialmzxsvf94nizf20kffdn986cz-guix-extra-modules.drv
/gnu/store/j5ni6cjgb55ri3qa2f7b8xpviy0jgkjr-guix-cli-modules.drv
/gnu/store/jj6hfbqfxjnvbsvz3g328png3nwsyxf6-guix-packages-modules.drv
/gnu/store/ww1jqx2wk19wbg342fin9k6p4qm6hv3i-guix-system-tests-modules.drv
/gnu/store/vd77mjsik676fqca9l23ljxgavxj5x4r-guix-daemon.drv
/gnu/store/a673nzfw8pdppwrb6m7xj0631qsb9z7k-profile.drv
/gnu/store/kbn57bk7ghw3qi8hk00gjyn5r2rdl3j1-inferior-script.scm.drv
19.7 MB will be downloaded
downloading from
https://ci.guix.gnu.org/nar/lzip/znswpawdi6wdd7a2jlh53ya7fscp5322-guix-packages-base
...
guix-packages-base 9.5MiB
3.1MiB/s 00:03 [##] 100.0%
downloading from
https://ci.guix.gnu.org/nar/lzip/9ba9smischbqpl5a12nfipcwwkb6bl1f-guix-system
...
guix-system
3.8MiB/s 00:02 | 7.1MiB transferred
Backtrace:
In guix/ui.scm:
2164:12 19 (run-guix-command _ . _)
In guix/scripts/substitute.scm:
652: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:
701:17 11 (_)
410:7 10 (process-substitution _ "/gnu/store/nvx8kkadjl81k5h544…" …)
In ice-9/boot-9.scm:
1736:10 9 (with-exception-handler _ _ #:unwind? _ # _)
In guix/scripts/substitute.scm:
419: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 (_ #<&compound-exception components: (#<&error> #<&irri…>)
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:
Throw to key `bad-response' with args `("Bad Response-Line: ~s" (""))'.
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:
Throw to key `bad-response' with args `("Bad Response-Line: ~s" (""))'.
substitution of /gnu/store/nvx8kkadjl81k5h544y4kahz6jlzqqyl-guix-system-tests
failed
guix pull: error: corrupt input while restoring archive from #
root@hamster ~#
unattended-upgrade-logs.tar.bz2
Description: Binary data
signature.asc
Description: PGP signature
Ideas for unattened-upgrades 1) auto service restarts, 2) reboot when needed
Thank you for unattended-upgrades! Something like it has been my main concern preventing deploying Guix on Internet-facing production machines. After using it for a while two things strikes me as useful improvements: 1) Automatically restarting all services. I manually specified mcron, ntpd and ssh-daemon as the services to restart, but this is not user friendly. I just noticed I forgot syslogd, nscd, guix-daemon and a bunch of others. Two ideas for improvements, mostly intended as food for discussion: 1.a) Have an option that run 'herd restart X' for all of the running services, probably except for some well-known system services that do not have running processes related to them anyway. I experimented with restarting all services mentioned by 'herd status', but some do not like to be restarted (maybe this is a separate issue?): root@hamster ~# herd restart device-mapping-/dev/md1 Service device-mapping-/dev/md1 has been stopped. Service device-mapping-/dev/md1 could not be started. root@hamster ~# herd start device-mapping-/dev/md1 Service device-mapping-/dev/md1 could not be started. herd: failed to start service device-mapping-/dev/md1 root@hamster ~# The device was still present and the filesystem on it was mounted. Further experimentation suggests the following should be excluded: device-mapping* file-system* root*. However, restarting some of others (including 'udev' and 'urandom-seed') restarts almost everything else so it is a bit wasteful. What do you think of this approach? It would be a loop doing 'herd restart X' on the service mentioned by 'herd status' except for some well-known services. Naturally, this should not be the default for now, but require a new unattended-upgrades variable, e.g. 'services-restart-all' set to true. 1.b) Look at te running processes on the system, and figure out which services started each, and restart each such service. I don't know if this is easily done. 2) Some upgrades requires a reboot for the effects to take place. At least this appears to includes the kernel and the transitive closure of all libraries and binaries involved in shepherd (pid 1). Libc upgrades are probably possible to handle in user-space (except for sheperd) but I believe other distributions reboot the machine on libc upgrades too. Unattended-upgrades could be extended with a list of packages that it should trigger a reboot for when they are upgraded. Probably this should also not be the default for now, but require another variable, e.g., 'reboot-when-needed' set to true. Btw, Happy holidays! /Simon signature.asc Description: PGP signature
