Re: guix git authenticate throws hard
Commit signing is a git feature, so git itself can be used to check your last commits are signed: git log --show-signature This will look the same as git log if the commit is unsigned, and show the result of gpg —verify otherwise. Red background if unverified (eg. you don't have the public key) and green otherwise. This should zake it easy to spot whether you signed the last commits or not Le 27 octobre 2022 02:07:40 GMT+02:00, jgart a écrit : >On Wed, 26 Oct 2022 09:07:57 +0200 Julien Lepiller wrote: >> It says fingerprint, so it's fingerprint. Using email or name would not be >> as secure. >> >> Le 26 octobre 2022 07:35:20 GMT+02:00, jgart a écrit : >> >On Wed, 26 Oct 2022 07:21:35 +0200 Julien Lepiller >> >wrote: >> >> From the manual: "signer is the OpenPGP fingerprint of public key used to >> >> sign commit.", but we should still catch this error :) >> > >> >Is it possible to give the email instead of the fingerprint? >> > >> >Deduce the fingerprint from the email? > >Julien and/or anyone else, > >What do you think if we have a CLI flag for git authenticate that would >allow us to do this to authenticate the last 5 commits against the >3B1D7F19E36BB60C0F5B2CA9A52AA2B477B6DD35 fingerprint, for example: > >guix git authenticate 3B1D7F19E36BB60C0F5B2CA9A52AA2B477B6DD35 -5 > >I've run into situations where I can't remember if I signed a commit or not. > >IWBC if I could just say authenticate the last commits against my >fingerprint instead of going one by one. If this already exists and is >not documented then we should definitely document that usage with an >example to let others know. > >all best, > >jgart
Re: Packages depending on (guix build syscalls)
Hello, Efraim Flashner writes: [...] >> It is great to have ‘font-abattis-cantarell’ built from source (since >> commit 97766323bc6e2b4dcfba4d6b46749a4280bca709), but it’s costly. >> >> There’s probably not much we can do, unless the python-afdko -> icedtea >> dependency is optional. >> >> Ideas? > > I looked into this one since it was causing mate to not appear for > i686-linux. I wasn't able to remove the java dependency for the font, > generating the font explicitly imports cffsubr. Python-cffsubr needs > python-afdko for the 'tx' command. I suppose we could re-bundle it but I > haven't gone down that rabbit hole yet. > > Or we could just make that font optional. The later sounds easiest, but is it really problematic to have Java as a transitive native input to GNOME? I mean, it already depends on Rust, and OpenJDK builds orders of times faster than Rust. -- Thanks, Maxim
GHC >= 9.0?
Hi, what's the status on packaging GHC >= 9.0? Is anyone working on that? all best, jgart
Re: guix git authenticate throws hard
On Wed, 26 Oct 2022 19:07:40 -0500 jgart wrote: > On Wed, 26 Oct 2022 09:07:57 +0200 Julien Lepiller wrote: > What do you think if we have a CLI flag for git authenticate I meant `guix authenticate` not `git authenticate` ;()
Re: guix git authenticate throws hard
On Wed, 26 Oct 2022 09:07:57 +0200 Julien Lepiller wrote: > It says fingerprint, so it's fingerprint. Using email or name would not be as > secure. > > Le 26 octobre 2022 07:35:20 GMT+02:00, jgart a écrit : > >On Wed, 26 Oct 2022 07:21:35 +0200 Julien Lepiller > >wrote: > >> From the manual: "signer is the OpenPGP fingerprint of public key used to > >> sign commit.", but we should still catch this error :) > > > >Is it possible to give the email instead of the fingerprint? > > > >Deduce the fingerprint from the email? Julien and/or anyone else, What do you think if we have a CLI flag for git authenticate that would allow us to do this to authenticate the last 5 commits against the 3B1D7F19E36BB60C0F5B2CA9A52AA2B477B6DD35 fingerprint, for example: guix git authenticate 3B1D7F19E36BB60C0F5B2CA9A52AA2B477B6DD35 -5 I've run into situations where I can't remember if I signed a commit or not. IWBC if I could just say authenticate the last commits against my fingerprint instead of going one by one. If this already exists and is not documented then we should definitely document that usage with an example to let others know. all best, jgart
Re: How long does it take to run the full rustc bootstrap chain?
Hi, On +2022-10-22 09:48:50 -0400, Maxim Cournoyer wrote: > Hi, > > Félix Baylac Jacqué writes: > > > Hey Guix, > > > > I'd be curious to know how long it takes to run the full rustc bootstrap > > chain on the Guix build farm. I'm sadly not sure how to approach this > > problem. > > > > Is there a way to extract this information from Cuirass or the Guix data > > service? > > > > Félix > > It used to be 16 hours on a Ryzen 3900x machine, then it got halved to 8 > hours with the work to bootstrap from 1.39, and recently we're > bootstrapping from 1.54, so it must have been greatly reduced again. > > Looking at (gnu packages rust), the mrustc-based bootstrap starts with > 1.54.0. This one is expensive, probably around 1 h 30 or more on a > Ryzen 3900x CPU (24 logical CPUs). > > The intermediate builds are typically around 15-20 minutes on that > machines, with the last one taking a bit more (30 minutes), so the > current bootstrap on such a machine should take about: > > 1.54.0: 1h30m > 1.55.0 - 1.60.0: 6 X 20 min = 1h20m > 1.60.0: final build with tests and extra tools: 30 min > > The total should be around 3 h 20 on a fast modern x86_64 machine. I > suppose the time for berlin to build it takes about this. > > HTH! > > -- > Thanks, > Maxim > I'm curious what --8<---cut here---start->8--- $ lsblk -o size,model,type,tran,vendor,name|grep -Ei 'ssd|model';echo;lspci |grep -i nvme --8<---cut here---end--->8--- on your relevant machines would show. I opted for the best SSD available for my purism librem13v4 at the time, and was really happy with seems like 10x faster than the SATA SSD in my older but still i7 x86_64 previous laptop. Prob really 4-5x faster. So above combo command line now gives me --8<---cut here---start->8--- SIZE MODEL TYPE TRAN VENDOR NAME 465.8G Samsung SSD 970 EVO Plus 500GB disk nvmenvme0n1 01:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM981/PM981 $ --8<---cut here---end--->8--- What /is/has been/ on your machines? Could your improved times be part from SSD/controller changes? There's really a huge difference between SATA and 4-lane pci (where both ends can handle it, which may require fw update or not be available) Obviously 4 lanes is also going to be faster than one. -- Regards, Bengt Richter
Re: emacs-guix (upstream) needs more love: a survey of repositories, homepage and issues
Hey all of you, I'm still interested. I go by teddd on IRC. I'll write you there Ludo. Cheers, Théo On Thu, Oct 6, 2022, 16:01 Ludovic Courtès wrote: > Hi Simon, Théo, Kaelyn, > > Simon Streit skribis: > > > Théo Maxime Tyburn writes: > >> It is here https://github.com/theottm/emacs-guix-clone. There is only > >> one branch. > >> > >>> if you succeed in building the new merged branch please notify me and > >>> I'll try to upstream it to > >>> https://git.savannah.gnu.org/cgit/guix/emacs-guix.git > >> > >> I just sucessfuly built it. You can probably use > > > > I could successfully build your branch. Unfortunately with geiser's > > recent upgrade from 0.23.2 to 0.26 emacs-geiser broke on my side. > > > > Geiser has since [1] removed all references to company. The end result > > is, that emacs-geiser will fail to load a REPL while it tries to > > initiate geiser-company. > > > > Here is my modification that fixes the REPL again: [2]. > > > > It'd be nice to see this pushed too and merge all the branches that now > > exist with emacs-guix. > > [...] > > > [1] > https://gitlab.com/emacs-geiser/geiser/-/commit/18faa0ba32c9ce751c16960b2a39b3880b523272 > > [2] https://git.steel-is-real.com/emacs-guix-clone/log/?h=simons-hack > > I’ve now merged your ‘simons-hack’ branch on Savannah. > > I’m sorry for dropping the ball here. I had told Kaelyn that they could > get an account on Savannah and become responsible for the Emacs-Guix > repo. The offer still holds, and it can even be extended to you Simon > and to Théo! > > As you can see I sometimes fail to follow up on issues, so I’d suggest > that you ping me on IRC (where I go by civodul) so we can proceed. > > Thank you! > > Ludo’. >
Re: Rust on aarch64-linux
On Sat, Oct 22, 2022 at 11:22:50PM +0300, Efraim Flashner wrote: > On Fri, Oct 21, 2022 at 10:51:59AM +0200, Ludovic Courtès wrote: > > Hello, > > > > Efraim Flashner skribis: > > > > > I'm not sure there is a bug report, I didn't see it either. It looks > > > like when I bumped rust-bootstrap from 1.39 to 1.54 we lost aarch64 > > > support. I've bumped mrustc on staging and successfully performed a > > > qemu-binfmt build of rust-bootstrap for aarch64 on my x86_64 box. I was > > > then able to use that to build rust-1.55 on actual aarch64 hardware, so > > > I assume it's good, I just don't have the hardware to build > > > rust-bootstrap for aarch64 natively. > > > > So the presumed fix involves bumping rust-bootstrap from 1.54 to 1.55, > > is that right? > > > > That means we’ll have to rebuild on all architectures. This is > > happening here: > > > > https://ci.guix.gnu.org/eval/739823 > > > > Could you monitor it? If things go well, can we aim for a merge by next > > Thursday? > > I think it looks good, but I'm not sure how to compare it to master. > perhaps some Magic View™ using the guix data service? I merged master into staging again and took a look at the build failures. They seemed alright (and I restarted a few) and then merged staging into master. Everything looks good from cuirass in relation to the merging. -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: guix git authenticate throws hard
It says fingerprint, so it's fingerprint. Using email or name would not be as secure. Le 26 octobre 2022 07:35:20 GMT+02:00, jgart a écrit : >On Wed, 26 Oct 2022 07:21:35 +0200 Julien Lepiller wrote: >> From the manual: "signer is the OpenPGP fingerprint of public key used to >> sign commit.", but we should still catch this error :) > >Is it possible to give the email instead of the fingerprint? > >Deduce the fingerprint from the email?
