bug#39615: LetsEncrypt root certificate hash changed
Tobias Geerinckx-Rice via Bug reports for GNU Guix writes: > Chris, > > Christopher Baines 写道： >> ~$ guix pull >> building >> /gnu/store/1r2cj292vvjvhbb92bri568p7dia7cp1-isrgrootx1.pem.drv... >> building >> /gnu/store/dhlb62lpf1ggcrax62hm7l7rlcf5c4fi-letsencryptauthorityx3.pem.drv... >> downloading from https://letsencrypt.org/certs/isrgrootx1.pem... >> -sha256 hash mismatch for >> /gnu/store/ahiiz5x04rqr214sw840ifz0d3jzmnsb-isrgrootx1.pem: >> expected hash: >> 0zycy85ff9ga53z1q03df89ka9iihb9p8bjhw056rq2y4rn3b6ac >> actual hash: >> 1la36n2f31j9s03v847ig6ny9lr875q3g7smnq33dcsmf2i5gd92 > > Thanks! I ran into this issue myself and updated the hashes in > 505b2631a9c35bbaa5ba6771ad4f646086f23cad. Great, thanks. However, while this change might avoid the problem with guix pull in the future, I still a bit stuck. I got this from a fresh install of Guix on the Overdrive machine I have (aarch64-linux). I'm hoping that I'll be able to install git and the Guix dependencies, download the repository, and then get a newer version of Guix that way, but I'm guessing this will still be a problem for other aarch64-linux machines unless there's a substitute out there somewhere. signature.asc Description: PGP signature
bug#39615: LetsEncrypt root certificate hash changed
Chris, Christopher Baines 写道： However, while this change might avoid the problem with guix pull in the future, I still a bit stuck. I got this from a fresh install of Guix on the Overdrive machine I have (aarch64-linux). I guess I've found my purpose this week and it's ‘mirroring old shit’. This is not at all a solution, but you can ‘guix download’ the old .pem files here[0] and hopefully be on your merry way. I'm hoping that I'll be able to install git and the Guix dependencies, download the repository, and then get a newer version of Guix that way, but I'm guessing this will still be a problem for other aarch64-linux machines unless there's a substitute out there somewhere. Indeed, and not just aarch64… Kind regards, T G-R [0]: https://www.tobias.gr/guix signature.asc Description: PGP signature
bug#39615: LetsEncrypt root certificate hash changed
Chris, Guix, Tobias Geerinckx-Rice via Bug reports for GNU Guix 写道： This is not at all a solution, but you can ‘guix download’ the old .pem files here[0] and hopefully be on your merry way. Actually: this shouldn't be necessary now, since I've copied these files to berlin (and created gcroots) which ought to serve them as substitutes. Kind regards, T G-R signature.asc Description: PGP signature
bug#39615: LetsEncrypt root certificate hash changed
Tobias Geerinckx-Rice writes: > Christopher Baines 写道： >> However, while this change might avoid the problem with guix pull in >> the >> future, I still a bit stuck. I got this from a fresh install of Guix >> on >> the Overdrive machine I have (aarch64-linux). > > I guess I've found my purpose this week and it's ‘mirroring old shit’. > > This is not at all a solution, but you can ‘guix download’ the old > .pem files here[0] and hopefully be on your merry way. Awesome, I've managed to download them and guix pull no longer fails with that error which is great :) signature.asc Description: PGP signature
bug#28659: bug#39575: guix time-machine fails when a tarball was modified in-place
Hi! zimoun skribis: > On Fri, 14 Feb 2020 at 22:34, Ludovic Courtès wrote: > >> Also, one could argue that we’d steer users towards downloading from our >> server, which could be a privacy concern (probably not a strong argument >> since one can easily change the substitute URLs.) > > I am not following the privacy concern. > What do you mean? I mean that by default, someone who’s disabled substitutes (presumably out of security or privacy concerns) would find themself downloading source code from ci.guix.gnu.org instead of various upstream sites. Ludo’.
bug#39614: icecat "profile cannot be loaded"
Nathan, Nathan Dehnel 写道： deleting the directory and --ProfileManager flag don't help Did you delete (back up) your entire ~/.mozilla, not just the ‘icecat’ subdirectory? Kind regards, T G-R signature.asc Description: PGP signature
bug#39632: Wrong keymap when decrypting master key
Hi,
I've installed Guix System manually in Gnome Boxes and asked for
encrypting the hard drive. When booting, Guix will ask 3 times for my
passphrase:
1. just after displaying Welcome to Grub, but before displaying the Grub
menu, Guix asks for my passphrase for hd0,gpt2
2. after the Grub menu, it asks for decrypting /dev/sda2
3. after that, it asks for decrypting /dev/sda3
I find it quite annoying to enter my passphrase 3 times. But even more
annoying, the first time, I have to enter it in Qwerty even though all
my system is supposed to be configured for Colemak:
(operating-system
(locale "en_US.utf8")
(timezone "Europe/Paris")
(keyboard-layout
(keyboard-layout "us" "colemak" #:options '("ctrl:nocaps")))
(bootloader
(bootloader-configuration
(bootloader grub-bootloader)
(target "/dev/sda")
(keyboard-layout keyboard-layout)))
Is there a way to enter my passphrase less often and/or always in
Colemak?
Thanks
--
Damien Cassou
"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill
bug#39632: Wrong keymap when decrypting master key
Damien, Damien Cassou 写道： I find it quite annoying to enter my passphrase 3 times. But even more annoying, the first time, I have to enter it in Qwerty even though all my system is supposed to be configured for Colemak: Didn't you already[0] report this bug as #39288? Then I'll merge the two. Kind regards, T G-R [0]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39288 signature.asc Description: PGP signature
bug#39637: mongo-tools test fail with Go 1.13
Hi Guix, After the recent Go 1.13 update, the test for mongo-tools package (currently at vervsion 3.4.0) fails with: ``` flag provided but not defined: -test.testlogfile Usage of /tmp/guix-build-mongo-tools-3.4.24.drv-0/go-build972699285/b001/mongofiles.test: -convey-json When true, emits results in JSON blocks. Default: 'false' -convey-silent When true, all output from GoConvey is suppressed. -convey-story When true, emits story output, otherwise emits dot output. When not provided, this flag mirros the value of the '-test.v' flag -test.types string Comma-separated list of the types of tests to be run (default "unit") FAILgithub.com/mongodb/mongo-tools/mongofiles 0.002s FAIL command "go" "test" "-v" "github.com/mongodb/mongo-tools/mongofiles" failed with status 1 ``` I believe that this is related to a change in Go's testing module with 1.13: https://golang.org/doc/go1.13#testing For more information, also see the Go bug report: https://github.com/golang/go/issues/31859 Note that mongo-tools provides a number of tools in different Go packages, and the mongofiles tool is the only one that has this error. I have tried to adding a call to flag.Parse() in TestMain, which I added, as described in the documentation [0], but that did not resolve the problem. I'm not exactly sure why. The same fix worked for containerd [1]. [0] https://golang.org/pkg/testing/#hdr-Main [1] http://git.savannah.gnu.org/cgit/guix.git/commit/?id=13c8e747e86e39c0a8c6ec7da8c812d9bbcb682b I wonder if the difference is that mongofiles does not use the flag package directly, but flag.Parse() is being called in the wrong place in one of its dependencies. A note on versions: the problem persists in the latest release of mongo-tools in the 3.4 series, 3.4.24. I have not tried the other release series, 3.6, 4.0, and 4.2 because those require dependencies not yet packaged in Guix. I have opened a bug report upstream: https://jira.mongodb.org/browse/TOOLS-2482 Thoughts or suggestions? Best, Jack
bug#39614: icecat "profile cannot be loaded"
Nathan Dehnel 写道： That worked, thank you. Great! Closing this bug, since it's both ‘fixed’ and not Guix-specific. Kind regards, T G-R signature.asc Description: PGP signature
bug#39614: icecat "profile cannot be loaded"
For the record, that probably means that a Firefox extension misbehaved. pgpnH4zjYVppa.pgp Description: OpenPGP digital signature
