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 files
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!
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 in
zimoun writes:
Maybe the length can be negative or zero. ;-)
‘Defensive programming’!
Thanks, :-)
T G-R
[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 ou
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 enc
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 refre
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 to
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
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 link
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,
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 it
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 system
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 boun
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 /gnu/store/12qcph6m26hlbyydsnl0ibl656397fld-fe-2
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
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 pack
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.
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 would
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 s
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?
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 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 chann
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).
> ./guix/store.scm:1373:1
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
Descript
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,
/gnu/store/cydvkyxdkkg7k9n04miy2
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.
>
> * gnu/packages/vi
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 yet,
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 pac
29 matches
Mail list logo
