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
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
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.
>
> *
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,
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
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).
>
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
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
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?
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
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
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.
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
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
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
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
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
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
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,
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
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
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
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
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
[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
zimoun writes:
Maybe the length can be negative or zero. ;-)
‘Defensive programming’!
Thanks, :-)
T G-R
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
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!
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
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
30 matches
Mail list logo
