bug#47559: GNU ELPA doesn't provide unzipped tarball for old version of package

2021-04-01 Thread Zhu Zihao
I found emacs-pyim failed to build because guix builder cannot download source from GNU ELPA. I check the page of pyim https://elpa.gnu.org/packages/pyim.html, and found that GNU ELPA only provides .tar.lz format source for old version of package. If GNU ELPA no longer provides stable url for

bug#42861: emacspeak won't shut up about TTS sync states

2021-04-01 Thread Kei
On Thu, 2021-04-01 at 17:30 +0200, Nicolas Goaziou wrote: > Hello, > > Kei writes: > > > Sorry it took me a while to respond. I don't actively use the openmailbox > > email > > account anymore. Please try this patch when you can. The sounds don't > > quite > > work like they do on Debian

bug#47541: libvirt does not work

2021-04-01 Thread Pierre Langlois
Hello! qblade via Bug reports for GNU Guix writes: > after this commit, the `virsh` does not work corrent: > > ``` > commit 383b02a370252c08eb1d43ac94d659c1d3993a35 > Author: Pierre Langlois > Date: Sat Mar 20 21:31:22 2021 + > > gnu: libvirt: Update to 7.1.0. > > *

bug#47428: Problems building the up-to-date "devel" manual for the website

2021-04-01 Thread Leo Famulari
This problem is still there. It's breaking the building of the primary manual, the devel manual, and the cookbook, both for HTML and PDF outputs. There are details in /var/log/mcron.log on the server. Basically, guile-html-index-en builds are failing. For example,

bug#47028: [PATCH 2/2] lint: Warn about single-character package names.

2021-04-01 Thread Tobias Geerinckx-Rice via Bug reports for GNU Guix
zimoun writes: My point is: I am not even sure that “r” should be whitelisted. I think it deserves the name, but my reasons are fuzzy and feely. Anyway: I added that exception for ‘r’ and pushed as 1126bb9cf33f10f004a5f53331389c777c025e75 et al. Kind regards, T G-R signature.asc

bug#47545: Guix bug on guix pull

2021-04-01 Thread Maxime Devos
On Thu, 2021-04-01 at 12:09 +0200, Zelphir Kaltstahl wrote: > Hi Guix Team! > > It seems my Guix has a bug and it asked me to report it to you: It seems "guix pull" starts with downloading substitutes (well, the daemon does the downloading, not the "guix pull" command). >

bug#47545: Guix bug on guix pull

2021-04-01 Thread Zelphir Kaltstahl
Hi Guix Team! It seems my Guix has a bug and it asked me to report it to you: $ guix pull Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'... Authenticating channel 'guix', commits 9edb3f6 to a266c9f (633 new commits)... Building from this

bug#33848: Store references in SBCL-compiled code are "invisible"

2021-04-01 Thread Mark H Weaver
Pierre Neidhardt writes: > I'm not familiar with the grafting code, so anyone who is (Mark? Ludo?) > might be able to fix this much quicker than me! :) I'll think about what would be required to modify our grafting code to support UCS-4. Mark

bug#33848: Store references in SBCL-compiled code are "invisible"

2021-04-01 Thread Mark H Weaver
Hi Ludovic, Ludovic Courtès writes: > What could have been nice is if there’s a way to mark specific strings > as being ASCII, or if there’s a “byte vector” data type compatible with > strings, for instance. Do we know that all strings containing store references will be representable in ASCII?

bug#42861: emacspeak won't shut up about TTS sync states

2021-04-01 Thread Nicolas Goaziou
Hello, Kei writes: > Sorry it took me a while to respond. I don't actively use the openmailbox > email > account anymore. Please try this patch when you can. The sounds don't quite > work like they do on Debian yet, but at least emacspeak doesn't go on and on > about the TTS sync state and

bug#33848: Store references in SBCL-compiled code are "invisible"

2021-04-01 Thread Ludovic Courtès
Pierre Neidhardt skribis: > I'm not familiar with the grafting code, so anyone who is (Mark? Ludo?) > might be able to fix this much quicker than me! :) There’s ‘%graft-hooks’ in (guix build graft). One could add a hook that would do nothing except for SBCL packages; for SBCL packages, it

bug#47451: Guix pull building lz4-1.9.3 fails

2021-04-01 Thread Leo Famulari
On Sun, Mar 28, 2021 at 04:10:36PM -0400, Leo Famulari wrote: > I think this bug was fixed in Guix in February: > > https://git.savannah.gnu.org/cgit/guix.git/commit/?id=78bbf6c44394c1024e0a369d0d5947e669606248 Closing... please let us know if the bug should be reopened.

bug#47544: rust-slice-deque is vulnerable to CVE-2021-29938

2021-04-01 Thread Léo Le Bouter via Bug reports for GNU Guix
CVE-2021-29938 07:15 An issue was discovered in the slice-deque crate through 2021-02-19 for Rust. A double drop can occur in SliceDeque::drain_filter upon a panic in a predicate function. Upstream PR: https://github.com/gnzlbg/slice_deque/pull/91 I suggest we wait for merge then update our

bug#47543: “Repeated allocation of very large block” during ‘guix pull’

2021-04-01 Thread Ludovic Courtès
While running ‘guix pull’, sometime between the actual ‘git pull’ (via Guile-Git) and channel authentication, I saw the dreaded libgc warning: Repeated allocation of very large block I forgot to capture the command output though, and it does not seem to be reproducible. (This is with a recent

bug#47472: fe: hash mismatch

2021-04-01 Thread Nicolas Goaziou
Hello, zimoun writes: > --8<---cut here---start->8--- > $ guix build -S --no-substitutes fe > The following derivation will be built: >/gnu/store/12qcph6m26hlbyydsnl0ibl656397fld-fe-2.0.tar.gz.drv > building

bug#47542: rust-stackvector package is vulnerable to CVE-2021-29939

2021-04-01 Thread Léo Le Bouter via Bug reports for GNU Guix
CVE-2021-29939 07:15 An issue was discovered in the stackvector crate through 2021-02-19 for Rust. There is an out-of-bounds write in StackVec::extend if size_hint provides certain anomalous data. No fix released upstream yet: https://github.com/Alexhuszagh/rust-stackvector/issues/2 Out of

bug#47509: OpenEXR may be vulnerable to CVE-2021-3474, CVE-2021-3476 and CVE-2021-3475

2021-04-01 Thread Léo Le Bouter via Bug reports for GNU Guix
Another wave it seems: CVE-2021-3479 31.03.21 16:15 There's a flaw in OpenEXR's Scanline API functionality in versions before 3.0.0-beta. An attacker who is able to submit a crafted file to be processed by OpenEXR could trigger excessive consumption of memory, resulting in an impact to

bug#41930: ‘guix pull’ shows raw build log output

2021-04-01 Thread Ludovic Courtès
Ludovic Courtès skribis: > The attached patch fixes that in an unimaginative but efficient fashion: > > 1. the parent process (which runs ‘build-self.scm’) accepts connections on > a named socket; > > 2. the ‘compute-guix-derivation’ process connects to that socket and > sends it

bug#47537: specification->package does not seem to support outputs

2021-04-01 Thread Leo Prikler
Hello, Am Donnerstag, den 01.04.2021, 03:50 + schrieb fsdfsdfsd3: > Hello, > > An example of this behavior in a guile repl is: > > (use-modules (gnu packages)) > (specification->package "qemu") ; works > (specification->package "qemu:doc") ; errors and closes the repl Given its docstring,

bug#33848: Store references in SBCL-compiled code are "invisible"

2021-04-01 Thread Pierre Neidhardt
Guillaume Le Vaillant writes: > Oh, you say this file would be created for every Lisp package. I thought > it would only be for the standalone binary case, because the "regular" > asdf-build-system/sbcl used for Lisp libraries ships the sources and its > make-asdf-configuration phase creates

bug#33848: Store references in SBCL-compiled code are "invisible"

2021-04-01 Thread Pierre Neidhardt
I'm not familiar with the grafting code, so anyone who is (Mark? Ludo?) might be able to fix this much quicker than me! :) -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature

bug#33848: Store references in SBCL-compiled code are "invisible"

2021-04-01 Thread Guillaume Le Vaillant
Pierre Neidhardt skribis: > Hi Guillaume! > >> A store reference to a C library in a standalone Lisp binary can come >> either from the current package or from some dependencies >> (cl+ssl, cl-cffi-gtk, etc.). So we would need to scan the source >> code of all the Lisp dependencies recursively

bug#33848: Store references in SBCL-compiled code are "invisible"

2021-04-01 Thread Pierre Neidhardt
Hi Guillaume! > A store reference to a C library in a standalone Lisp binary can come > either from the current package or from some dependencies > (cl+ssl, cl-cffi-gtk, etc.). So we would need to scan the source > code of all the Lisp dependencies recursively to get the full list of > store

bug#33848: Store references in SBCL-compiled code are "invisible"

2021-04-01 Thread Guillaume Le Vaillant
Pierre Neidhardt skribis: > If we are going for a SBCL-specific solution, I believe that all > references are stored in plain text files at some points (the .asd files > and the .lisp files) which are often encoded in ASCII / UTF-8, so > searching these files without having to deal with their

bug#47028: Discourage single-character package names

2021-04-01 Thread Tobias Geerinckx-Rice via Bug reports for GNU Guix
[Inexcusably breaking thread because I lost the original.] Mark, We have one notable exception in Guix: "r", which is "grandfathered in" so-to-speak [...] Very good point. So grandfathered it didn't occur to me. [...] perhaps "r"should be whitelisted. I agree. Thanks for pointing it

bug#47028: [PATCH 2/2] lint: Warn about single-character package names.

2021-04-01 Thread Tobias Geerinckx-Rice via Bug reports for GNU Guix
zimoun writes: Maybe the length can be negative or zero. ;-) ‘Defensive programming’! Thanks, :-) T G-R

bug#33848: Store references in SBCL-compiled code are "invisible"

2021-04-01 Thread Ludovic Courtès
Hi, Mark H Weaver skribis: > Pierre Neidhardt writes: >> - The main recommendation for an easy fix without updating the scanner >> is that we tweaked our build system to dump the store reference to a >> separate ASCII file. > > Sounds good. I made a similar proposal in Dec 2018, earlier

bug#47537: specification->package does not seem to support outputs

2021-04-01 Thread fsdfsdfsd3 via Bug reports for GNU Guix
Hello, An example of this behavior in a guile repl is: (use-modules (gnu packages)) (specification->package "qemu") ; works (specification->package "qemu:doc") ; errors and closes the repl (specification->package+output "qemu:doc") ; works as expected Thank you!

bug#33848: Store references in SBCL-compiled code are "invisible"

2021-04-01 Thread Pierre Neidhardt
Thank you for the reminder, Mark, I had forgotten about your suggestion. If we are going for a SBCL-specific solution, I believe that all references are stored in plain text files at some points (the .asd files and the .lisp files) which are often encoded in ASCII / UTF-8, so searching these

bug#33848: Store references in SBCL-compiled code are "invisible"

2021-04-01 Thread Mark H Weaver
Pierre Neidhardt writes: > - The main recommendation for an easy fix without updating the scanner > is that we tweaked our build system to dump the store reference to a > separate ASCII file. Sounds good. I made a similar proposal in Dec 2018, earlier in this thread