bug#60852: git-authenticate edge case for certain key setup.
I encountered the issue when adding a new key to my Guix channel. Though I
haven't figured out what happened exactly, I'm currently able to reproduce the
issue with the following steps.
1. Generate two keypairs. Key One with the preset "ECC and ECC", Key Two with
"ECC (set your own capabilities)" and only keep the Certify capability, then
add a Sign subkey to Key Two. All Curve 25519.
#+RESULTS:
: /tmp/test/pubring.kbx
: -
: sec ed25519/676A52381FFD80C5 2023-01-16 [SC]
: Key fingerprint = 21D3 9304 CED7 A5CF 50B6 0B80 676A 5238 1FFD 80C5
: uid [ultimate] Key One
: ssb cv25519/BA35E2E29D6E4CE4 2023-01-16 [E]
: Key fingerprint = 450A DF8C 6FE4 AEFF EC75 EBD9 BA35 E2E2 9D6E 4CE4
:
: sec ed25519/06DE4CED9A91AB7B 2023-01-16 [C]
: Key fingerprint = 4A45 EC76 DA2B 389A FE2F C887 06DE 4CED 9A91 AB7B
: uid [ultimate] Key Two
: ssb ed25519/3BE8CD60E408A705 2023-01-16 [S]
: Key fingerprint = 405C B557 DE1F 1254 B012 640A 3BE8 CD60 E408 A705
2. Create a new git repository, commit public keys of the two to the "keyring"
branch. Then commit file ".guix-authorizations" to the "main" branch with the
following code:
#+begin_src scheme
(authorizations
(version 0)
(("21D3 9304 CED7 A5CF 50B6 0B80 676A 5238 1FFD 80C5"
(name "Key One"
#+end_src
Configure git to sign commits with Key One, change the ".guix-authorizations"
file to the following and commit:
#+begin_src scheme
(authorizations
(version 0)
(("21D3 9304 CED7 A5CF 50B6 0B80 676A 5238 1FFD 80C5"
(name "Key One")))
(("405C B557 DE1F 1254 B012 640A 3BE8 CD60 E408 A705"
(name "Key Two"
#+end_src
Then change the signing key to Key Two and add a new commit.
Now there're three commits:
#+RESULTS:
: commit 5240baeebc055187fb738e66e7dbfbb57c0aeba3 (HEAD -> main)
: Author: Test
: Date: Mon Jan 16 13:53:49 2023 +0800
:
: test
:
: commit a6794b64f9dfa828a5721e3f02c27ab74db9a487
: Author: Test
: Date: Mon Jan 16 13:53:17 2023 +0800
:
: Authorize Key Two.
:
: commit c9476062a2f341e9ee95a60d17cf2233b7c55ff4
: Author: Test
: Date: Mon Jan 16 13:51:02 2023 +0800
:
: Authorize Key One.
3. Invoke `guix git authenticate`...with error.
#+begin_src shell
guix git authenticate c9476062a2f341e9ee95a60d17cf2233b7c55ff4 "21D3 9304
CED7 A5CF 50B6 0B80 676A 5238 1FFD 80C5"
#+end_src
#+RESULTS:
: Authenticating commits c947606 to 5240bae (1 new commits)...
:
[##]guix
git: error: commit 5240baeebc055187fb738e66e7dbfbb57c0aeba3 not signed by an
authorized key: 405C B557 DE1F 1254 B012 640A 3BE8 CD60 E408 A705
4. However, if I swap positions of the two fingerprints, it works.
New ".guix-authorizations" file:
#+begin_src scheme
(authorizations
(version 0)
(("405C B557 DE1F 1254 B012 640A 3BE8 CD60 E408 A705"
(name "Key Two")))
(("21D3 9304 CED7 A5CF 50B6 0B80 676A 5238 1FFD 80C5"
(name "Key One"
#+end_src
New commits history:
#+RESULTS:
: commit 7e4d98eea0e89652554d822503096371e5d59f3b (HEAD -> main)
: Author: Test
: Date: Mon Jan 16 14:52:37 2023 +0800
:
: test
:
: commit a44434b1a9bd955cc897dea4c44abe64d6ab8112
: Author: Test
: Date: Mon Jan 16 13:53:49 2023 +0800
:
: Swap positions of the two fingerprints.
:
: commit a6794b64f9dfa828a5721e3f02c27ab74db9a487
: Author: Test
: Date: Mon Jan 16 13:53:17 2023 +0800
:
: Authorize Key Two.
:
: commit c9476062a2f341e9ee95a60d17cf2233b7c55ff4
: Author: Test
: Date: Mon Jan 16 13:51:02 2023 +0800
:
: Authorize Key One.
And a new `guix git authenticate` result:
#+RESULTS:
: Authenticating commits c947606 to 7e4d98e (2 new commits)...
若
bug#60816: guix pull ("computing Guix derivation") is not reproducible
Hi, On +2023-01-15 15:35:31 +0100, Josselin Poiret via Bug reports for GNU Guix wrote: > Hi again Julien, > > Julien Lepiller writes: > > > it seems that on one machine, my .cache/guix/checkouts got polluted by > > uncommited files. I have no idea why they're there, but cleaning them > > should solve my issue, thanks! > > It's not the first time we've seen this, we could probably consider > adding a git clean after the reset in switch-to-ref. > > Best, > -- > Josselin Poiret Could wrong timestamps on pushed files cause problems? E.g., if you were working offline on a laptop where cat /proc/driver/rtc was significantly wrong at boot time, perhaps due to flaky CMOS battery, or error in init specs? If you didn't connect to the internet and get synced, couldn't you wind up with files with bad time stamps? (I think I can dig up evidence of that, when I didn't connect, though I don't show it here). Could some Makefile action or some date-sensitive find or if [[ file1 -nt file2 ]] then be wrongly triggered and leave mystery files around? IWT synchronizing distributed monotonic time has to have been solved a long ago, but old unnoticed errors do seem to wake up sometimes in new circumstances. I have been having mystery problems with time, which I have yet to diagnose properly. One theory that matches some symptoms is if there is a virtualized /proc/driver/rtc which gets a bogus value temporarily, which gets accessed and stored by whatever stores time as boot time for who -b to see forever (until shutdown) -- but date and other time functions see the virtual /proc/driver/rtc every time, not a cached value, so they get corrected shortly after internet is connected. But what happens to file time stamps if you don't connect to the internet for a long time? BTW,I see the bad time at the top of the screen right after boot but before reaching login, and IIRC it will currect to local without logging in if I plug in the internet dongle. Shown below I just booted from cold power-off, with 99% main battery, about 17:20, so how to explain bogus who -b system boot time of 07:53 this morning? From that timee uptime at 17:20:06 would be: 9hrs 27min 6sec, not "1:14" (1hr 14min)) Well, I guess the 9 hours could be explained by root having a different idea of locale at pre-internet boot time, but the 27min 6 sec? --8<---cut here---start->8--- who -b; uptime;date -Ins;grep rtc /proc/driver/rtc system boot 2023-01-15 07:53 17:20:06 up 1:14, 1 user, load average: 0.00, 0.08, 0.15 2023-01-15T17:20:06,768027575+01:00 rtc_time: 16:20:06 rtc_date: 2023-01-15 --8<---cut here---end--->8--- Also some anomalies in dmesg and journalctl -b, but inconclusive for me ;/ I noticed the bad "who -b" times because whenever my ~/.bash_profile sees a change as I log in, it uses the date to create a new scratch "boot-session" directory and updates a symbolic link to it at ~/bs like stat -c %N ~/bs shows: '/home/bokr/bs' -> '/home/bokr/BS/bs20230115_0753' which is annoyingly wrong. It also makes a link to the previous ~/bs in the new, like '/home/bokr/bs/pbs' -> '../bs20230113_0427' (showing some insomnia ;/ ) but if I cd ~/bs PS1 will display a nice short prompt :) --8<---cut here---start->8--- [01:53 ~/bs]$ cd ~/bs [01:53 ~/bs]$ realpath . /home/bokr/BS/bs20230115_0753 [01:53 ~/bs]$ realpath ~/bs /home/bokr/BS/bs20230115_0753 [01:54 ~/bs]$ --8<---cut here---end--->8--- HTH & SFTN if this is not useful or relevant. -- Regards, Bengt Richter
bug#60844: no text in Anki
I recently installed Anki and added some decks to study Japanese. However, I only see cog icons when I open Anki. Clicking them does pop up a settings menu and I can see their names there. Is this a QtWebkit bug again? I tried the sandbox workaround I saw in some other bug report but it did not help.
bug#57493: [EXT] Re: bug#57493: should allow for customizing home directory permission bits
Hi Liliana, On Sun, Jan 15, 2023 at 7:25 AM Liliana Marie Prikler wrote: > > * gnu/system/accounts.scm > > ()[home-directory-permissions]: New > > field. > > (user-account-home-directory-permissions): New accessor. > > * gnu/build/activation.scm (activate-users+groups): Use home > > directory > > permission bits from the user account object. > > * doc/guix.texi (User Accounts): Document new field. > LGTM. > > The header says this is part 1/2. Is that correct or did you just > invoke git format-patch wrong? Oops, that's my bad! I forgot that the patch file header would say that. There's a second patch that changes the Gitolite service to use this new field, which is the service that sparked the need for this additional flexibility, but I was going to leave that out for now and maybe just push directly as it's a 2 line change and the gitolite system test passes. So, please disregard that 1/2 thing! Thanks for checking! - Dave
bug#60566: [PATCH] environment: Fix '--emulate-fhs' option overriding $PATH.
Hi Ludo’, On Sat, Jan 14, 2023 at 03:41 PM, Ludovic Courtès wrote: > Hi John, > > John Kehayias skribis: > > [...] > >> - (setenv "PATH" "/bin:/usr/bin:/sbin:/usr/sbin") >> + (setenv "PATH" (string-append "/bin:/usr/bin:/sbin:/usr/sbin" >> + (when (getenv "PATH") >> + (string-append ":" (getenv >> "PATH") > > Remember that ‘when’ returns *unspecified* when the condition is false, > so you’d get a type error here when PATH is undefined. > > Instead write: (if (getenv "PATH") … ""). > Ah yes, my Common Lisp showing through and relying on nil instead. Fixed and thanks! >> +# Test that $PATH inside the container has FHS directories. >> +guix shell -CF --bootstrap guile-bootstrap \ >> + -- guile -c '(exit (if (string-contains (getenv "PATH") >> +"/bin:/usr/bin:/sbin:/usr/sbin") >> + 0 >> + 1))' > > Even (exit (string=? (getenv "PATH") "/bin:/usr/bin:/sbin:/usr/sbin")). > With this patch PATH now gets the FHS directories in addition to what it normally has (like the profile's bin directory). While slightly redundant, this seems to be better than clobbering it. Anyway, so we can't check that the PATH is completely equal here. >> +# Make sure '--preserve' is honored for $PATH, which the '--emulate-fhs' >> +# option will modify. We can't (easily) check the whole $PATH as it will >> +# differ inside and outside the container, so just check for an added >> string. >> +PATH=this-is-a-test:$PATH guix shell -CF --bootstrap guile-bootstrap -E >> PATH \ >> + -- guile -c '(exit (if (string-contains (getenv "PATH") >> +"this-is-a-test") >> + 0 >> + 1))' > > It might be slightly more concise with ‘env’: > > PATH=/foo $(type -P guix) shell -E ^PATH$ -C coreutils -- env |grep > ^PATH=.*:/foo > > (I think ‘--bootstrap’ doesn’t buy us much here because we have to > download/build ‘glibc-for-fhs’ anyway. ‘--bootstrap’ and > ‘guile-bootstrap’ are particularly useful for testse that can run > without network access and without building tons of stuff, as in > ‘tests/guix-environment.sh’ for instance.) > Ah, thanks, that is nicer if we can just use coreutils. I rewrote the previous test to use that as well. Probably some other tests here could use that simplification, but outside of the scope here. (Side note that 'type' in zsh works differently, one could use 'whence' there or even the built-in 'which'. For the tests we are running with bash or bash compliant here, so it is not a problem.) > Otherwise LGTM, thanks! > > Ludo’. Thanks again for your careful review! Pushed as 3bfbfa2946aebb7f68c8027ae80f272f6915c94f and closing this issue. Thanks also for jman for reporting. John
bug#56709: (No Subject)
> > i'm also seeing this, and the solution was to comment > > out the (identity ...) field of my machine-ssh-configuration. > > > i spoke too soon. today it's again broken for me the same way, even > though identity is commented out. lechner on IRC also reported that > it's broken for him. since then it's working again. this seems to be some transient issue. possibly related to network state? note that normal SSH always works. it's only a late phase of `guix deploy` where this error sometimes shows up. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “The most urgent necessity is, not that the State should teach, but that it should allow education. All monopolies are detestable, but the worst of all is the monopoly of education.” — Frédéric Bastiat (1801–1850), 'What Is Money?'
bug#60831: [PATCH] gnu: emacs-minimal: Do not patch compilation driver.
The ‘patch-compilation-driver’ phase pulls in libgccjit even though it has been deliberately removed from emacs-minimal. * gnu/packages/emacs.scm (emacs)[#:phases]: Delete ‘patch-compilation-driver’. --- Thanks Josselin for pointing this out. gnu/packages/emacs.scm | 1 + 1 file changed, 1 insertion(+) diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm index 97d46486c7..83b9afb633 100644 --- a/gnu/packages/emacs.scm +++ b/gnu/packages/emacs.scm @@ -448,6 +448,7 @@ (define-public emacs-minimal ((#:phases phases) #~(modify-phases #$phases (delete 'set-libgccjit-path) +(delete 'patch-compilation-driver) (delete 'restore-emacs-pdmp) (delete 'strip-double-wrap) (inputs (list ncurses coreutils gzip)) -- 2.38.1
bug#60816: guix pull ("computing Guix derivation") is not reproducible
Hi again Julien, Julien Lepiller writes: > it seems that on one machine, my .cache/guix/checkouts got polluted by > uncommited files. I have no idea why they're there, but cleaning them > should solve my issue, thanks! It's not the first time we've seen this, we could probably consider adding a git clean after the reset in switch-to-ref. Best, -- Josselin Poiret
bug#60834: configuration->documentation generates garbage @-command on fields beginning with numeric characters
Minimal example (with Guix REPL):
--8<---cut here---start->8---
scheme@(guix-user)> ,use (gnu services configuration)
scheme@(guix-user)> (define serialize-boolean (lambda (x y) #t))
scheme@(guix-user)> (define-configuration example-configuration (1-foo (boolean
#t) "lorem ipsum"))
scheme@(guix-user)> (configuration->documentation 'example-configuration)
%example-configuration
@c %start of fragment
@deftp {Data Type} example-configuration
Available @code{example-configuration} fields are:
@table @asis
@item @code{#@{1-foo@}#} (default: @code{#t}) (type: boolean)
lorem ipsum
@end table
@end deftp
@c %end of fragment
scheme@(guix-user)>
--8<---cut here---end--->8---
bug#60831: Are our graphs okay?
Hi Lily, Liliana Marie Prikler writes: > This is rather curious. How does libgccjit land in emacs-minimal's > closure? The patch-compilation-driver phase in the inherited emacs package wires in a reference to libgccjit. It would need to be replaced in emacs-minimal. Best, -- Josselin Poiret
bug#60816: guix pull ("computing Guix derivation") is not reproducible
Le Sun, 15 Jan 2023 12:54:45 +0100, Josselin Poiret a écrit : > Hi Julien, > > Julien Lepiller writes: > > > So, apart from the output filename which obviously changes, it seems > > that the differences are: > > > > - order of dependencies, > > - source output, > > - builder (only because it references the source output) > > > > Here's the result of diffoscope on the source outputs (ignore > > modification date, I used touch to make them all the same, not to > > make them sensible ;)): > > > > [...] > > > > Could it be that removed files are somehow kept in cache? > > Does this still happen if you run `git clean -df` in both of your > local checkouts? > > Best, Haha! it seems that on one machine, my .cache/guix/checkouts got polluted by uncommited files. I have no idea why they're there, but cleaning them should solve my issue, thanks!
bug#60831: Are our graphs okay?
Hi Guix, Continuing the discussion Ludo’ started over at guix-devel regarding package size, note that we have $ guix size emacs-minimal Store-Objekt Gesamt Selbst /gnu/store/lphzb1z0r4kbb453rsvnw7msrxxzp5r7-libgccjit-10.3.0 244.8 128.5 27.2% /gnu/store/wrzjr2g38f23fqg09rrdcn10va5gc5xl-emacs-minimal-28.2 472.4 110.7 23.4% /gnu/store/zyqimpkmpffc24nwwqp46cicj8ss85y5-binutils-2.37 126.0 54.4 11.5% /gnu/store/ayc9r7162rphy4zjw8ch01pmyh214h82-glibc-2.33 76.6 36.6 7.8% /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33 38.3 36.6 7.7% /gnu/store/6d0pl5khj08j3c2619jnypc8bznspgx8-gcc-10.3.0-lib 71.7 33.4 7.1% /gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib 71.7 33.4 7.1% /gnu/store/8fpk2cja3f07xls48jfnpgrzrljpqivr-coreutils-8.32 91.6 16.4 3.5% /gnu/store/9rrnm5hdjw7cy96a2a9rfgh6y08wsbmf-ncurses-6.2.2021061977.6 5.9 1.3% /gnu/store/pmq05n0q25v4qjyibxfrp53v4391k7vh-mpfr-4.1.0 78.4 4.0 0.9% /gnu/store/ajw8nnrnd6hr183skwqdgc8c7mazg97h-isl-0.2377.3 2.9 0.6% /gnu/store/fwbiihd2sbhai63y1pvvdh0f2bakfzrf-gmp-6.2.1 74.4 2.7 0.6% /gnu/store/4f304c7dp68hkcp1zi1i07zm8nfvvyp7-bash-static-5.1.81.7 1.7 0.4% /gnu/store/720rj90bch716isd8z7lcwrnvz28ap4y-bash-static-5.1.81.7 1.7 0.4% /gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8 39.3 1.0 0.2% /gnu/store/xjwp2hsd9256icjjybfrmznppjicywf6-grep-3.673.5 0.8 0.2% /gnu/store/ba02g5xkqiss6s5z8mbj9cvkal6l7b9g-mpc-1.2.1 78.8 0.4 0.1% /gnu/store/a38k2v29l6l0iz6pmlk4dmzwdbvl10lq-acl-2.3.1 72.3 0.3 0.1% /gnu/store/a7ggx0af69gv4k5mr1k617p4vy9kgx2v-libcap-2.62 72.0 0.3 0.1% /gnu/store/jkjs0inmzhj4vsvclbf08nmh0shm7lrf-attr-2.5.1 71.9 0.2 0.1% /gnu/store/8qv5kb2fgm4c3bf70zcg9l6hkf3qzpw9-zlib-1.2.11 71.9 0.2 0.0% /gnu/store/0c1yfbxyv877mlgychfgvmk5ha2jqh52-gzip-1.10 73.7 0.2 0.0% Gesamt: 472.4 MiB but $ guix graph --path emacs-minimal libgccjit guix graph: Fehler: Kein Pfad von „emacs-minimal@28.2“ nach „libgccjit@12.2.0“ and $ guix graph --path /gnu/store/wrzjr2g38f23fqg09rrdcn10va5gc5xl-emacs- minimal-28.2 /gnu/store/lphzb1z0r4kbb453rsvnw7msrxxzp5r7-libgccjit- 10.3.0 --type=referrers guix graph: Fehler: Kein Pfad von „/gnu/store/wrzjr2g38f23fqg09rrdcn10va5gc5xl-emacs-minimal-28.2“ nach „/gnu/store/lphzb1z0r4kbb453rsvnw7msrxxzp5r7-libgccjit-10.3.0“ This is rather curious. How does libgccjit land in emacs-minimal's closure?
bug#57493: should allow for customizing home directory permission bits
* gnu/system/accounts.scm > ()[home-directory-permissions]: New > field. > (user-account-home-directory-permissions): New accessor. > * gnu/build/activation.scm (activate-users+groups): Use home > directory > permission bits from the user account object. > * doc/guix.texi (User Accounts): Document new field. LGTM. The header says this is part 1/2. Is that correct or did you just invoke git format-patch wrong? Cheers
bug#60816: guix pull ("computing Guix derivation") is not reproducible
Hi Julien, Julien Lepiller writes: > So, apart from the output filename which obviously changes, it seems > that the differences are: > > - order of dependencies, > - source output, > - builder (only because it references the source output) > > Here's the result of diffoscope on the source outputs (ignore > modification date, I used touch to make them all the same, not to make > them sensible ;)): > > [...] > > Could it be that removed files are somehow kept in cache? Does this still happen if you run `git clean -df` in both of your local checkouts? Best, -- Josselin Poiret
bug#60821: "failed to compute the derivation" and openssl build failure
Hi Zach, Zach Philipchook writes: > Hi! > > I installed guix on Ubuntu 20.04 from a tarball and I'm getting an error > while doing an initial `guix pull`. Apparently, openssl fails to build. > > The command output: https://pastebin.com/BVvdcXX2 > The openssl build ouput: https://pastebin.com/Kpn0avU1 This second pastebin is not available anymore. You don't need to use paste services when using mailing lists, you can just send the log files as long as they are not too huge (and if they are, just strip the irrelevant parts). In the meantime, what tarball are you using? 1.4.0? Best, -- Josselin Poiret
