bug#57611: [PATCH] Addressing bug#57611 by updating rust-wayland-client and rust-wayland-scanner dependencies

Hi, This is my first patch to Guix (and my first time submitting a patch by mailing list), so I'd love whatever feedback y'all have to offer! Trying to address the alacritty build issue. As of now, alacritty won't build because rust-wayland-scanner can't be built. After chasing many

bug#57559: guix pull fails on http status code 503

On 06-09-2022 15:09, zimoun wrote: The initial report by André is about: --8<---cut here---start->8--- $ guix pull Updating channel 'nonguix' from Git repository at 'https://gitlab.com/nonguix/nonguix'... guix pull: error: Git error: unexpected http status

bug#57653: pypy build fails due to a readelf error in validate-runpath

Hello, The pypy build fails like so: --8<---cut here---start->8--- phase `strip' succeeded after 0.2 seconds starting phase `validate-runpath' validating RUNPATH of 4 binaries in "/gnu/store/qdypiywzkz71rayp9h2fipgj4cjksrg9-pypy-7.3.5/bin"...

bug#57611: rust-once-cell (alacritty dependency) build failure

On 07-09-2022 01:15, Ben Van Sleen wrote: Subject: bug#57611: rust-once-cell (alacritty dependency) build failure From: Ben Van Sleen Date: 07-09-2022 01:15 To: 57...@debbugs.gnu.org rust-once-cell-1 can't be built because it now depends on rust-parking-lot-core-0.9. This can't be built

bug#57436: Running ./configure from `guix shell -D guix --pure` errors

On Mon, Aug 29, 2022 at 1:29 PM zimoun wrote: > Do you mean update the «Building from Git» section? Yes this is what I mean.

bug#57593: Racket 8.6 is not reproducible

Hi, On Mon, Sep 5, 2022, at 6:04 AM, Ludovic Courtès wrote: > Hey, > > Just noticed that Racket does not build in a reproducible fashion: > > --8<---cut here---start->8--- > $ guix describe > Generation 227 Sep 04 2022 23:39:52(current) > guix aae98c2 >

bug#57581: Failing to build the website

Le 7 septembre 2022 19:07:10 GMT+02:00, zimoun a écrit : >Hi, > >Well, the field reads, > >+(license (package-home-page qtbase > >so why is the compiler accepting that? Is a warning raised? > No warning because the compiler has no way to know you don't want to do that. license is a

bug#57581: Failing to build the website

Hi, On Wed, 07 Sep 2022 at 18:31, "pelzflorian (Florian Pelz)" wrote: > zimoun writes: >> The culprit seems the package ’qtserialport’ in ’packages-builder’ from >> (apps packages builder). Maybe introduced by commit >> 1ef04fb2288dade3ad2883026ae286a68ef13a1e. > > This was a first failing

bug#57647: r-irkernel: kernel name conflict when multiple versions of R are used

Hi, I've noticed that when I install r-irkernel it also defines the kernel entry in {profile}/share/jupyter with ir name. If I install again r-irkernel, but with another R version / different profile, the kernel name is again named ir. This is not an issue when each profile is used

bug#57648: python-bash-kernel : No module named bash_kernel

Hi, I've tried to use python-bash-kernel (via jupyterhub), but, even the package installation defines correctly the kernel $ cat .guix-profile/share/jupyter/kernels/bash/kernel.json {"argv": ["/gnu/store/1m48ama708vh9cjn79yw6cj8sgg7pa1b-python-wrapper- 3.9.9/bin/python", "-m", "bash_kernel",

bug#57611: rust-once-cell (alacritty dependency) build failure

rust-once-cell-1 can't be built because it now depends on rust-parking-lot-core-0.9. This can't be built because it now requires rust-windows-sys-0.36 according to the crates page ( https://crates.io/crates/parking_lot_core/0.9.3/dependencies). This package definition can be found in the guix

bug#57581: Failing to build the website

zimoun writes: > The culprit seems the package ’qtserialport’ in ’packages-builder’ from > (apps packages builder). Maybe introduced by commit > 1ef04fb2288dade3ad2883026ae286a68ef13a1e. This was a first failing commit for me too, but the reason the website does not build appears to be the

bug#57576: bug#57599: [PATCH] openpgp: Add support for ECDSA with NIST curves.

Hi, On Wed, 07 Sep 2022 at 14:51, Ludovic Courtès wrote: > I’d like to see what other free software OpenPGP implementors decided > (primarily Sequoia; GnuPG/Libgcrypt implement them). Maybe related . Cheers, simon

bug#57642: [PATCH] gnu: linux: Fix unnecessary let clause in make-linux-libre.

Hey, > * gnu/packages/linux.scm (make-linux-libre*)[arguments]: > Remove unnecessary let clause in 'configure phase. You should send such patches to "guix-patc...@gnu.org" instead as it is not a bug report nor correction. Pushed as 2183db8d2 :). Thanks, Mathieu

bug#57576: bug#57599: [PATCH] openpgp: Add support for ECDSA with NIST curves.

Hi, Thanks a lot for the explanations, Andreas! As you write, the decision will be “political” as there’s no scientific evidence to guide us. I’d like to see what other free software OpenPGP implementors decided (primarily Sequoia; GnuPG/Libgcrypt implement them). Ludo’.

bug#57576: bug#57599: [PATCH] openpgp: Add support for ECDSA with NIST curves.

Am Wed, Sep 07, 2022 at 01:13:25PM +0200 schrieb Maxime Devos: > Also, we _do_ have concrete evidence that the curves are flawed -- the website > on the link mentions many issues in the process The website (you mean the blog by D. Bernstein?) also mentions the use of a hash function to arrive at

bug#57642: [PATCH] gnu: linux: Fix unnecessary let clause in make-linux-libre.

* gnu/packages/linux.scm (make-linux-libre*)[arguments]: Remove unnecessary let clause in 'configure phase. --- gnu/packages/linux.scm | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm index f4880f164c..ee6e592183 100644 ---

bug#57576: bug#57599: [PATCH] openpgp: Add support for ECDSA with NIST curves.

On 06-09-2022 22:02, Ludovic Courtès wrote: In case of those curves, I'm not aware of any 'crytopgraphic proof' (*) that the curves are vulnerable (unlike for SHA-1), but as noted in ¹ and elsewhere, there are other kinds of evidence that something is wrong. It’s different from SHA-1 though:

bug#57576: bug#57599: [PATCH] openpgp: Add support for ECDSA with NIST curves.

Hello, Am Tue, Sep 06, 2022 at 10:02:55PM +0200 schrieb Ludovic Courtès: > (Cc’ing Andreas for extra advice.) well, I agree with your analysis. There is no concrete evidence that the NIST curves may be flawed, and a general belief that not all crypto standards of NIST are flawed or backdoored...