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

[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 packages, we may need to
adjust elpa importer to use Git repo if possible. And we also need to
fix packages depend on GNU ELPA url because they may be broken in future.
-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

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

[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 yet, but at least emacspeak doesn't go on and on
> > about the TTS sync state and such.
> 
> This is much better indeed. Thank you.
> 

My pleasure!

> On Debian espeak seems to be activated after loading ".emacs" file.

How are you able to tell (aside from looking at the command line arguments)? 
I'm unable to distinguish the startup processes using Emacs on Debian and Guix
even if I install "etc/emacspeak.sh" as the startup script instead of "run".

> Here, the package spells out all configuration messages displayed on in
> the minibuffer.
> 

Unless I'm misunderstanding you, Emacspeak seems to do the same for me on
Debian.  For example, it reads "Active processes exist?..." and so on when
exiting.  Is this not proper behavior?

Thanks,
Kei

bug#47541: libvirt does not work

[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.
>
> * gnu/packages/virtualization.scm (libvirt): Update to 7.1.0.
> [source]: Remove libvirt-create-machine-cgroup.patch, add
> libvirt-do-not-create-var-dirs.patch.
> [build-system]: Switch to meson-build-system.
> [arguments]: Use meson-0.55.  Adapt #:configure-flags for meson, there is 
> no
> need for --docdir anymore.  Remove fix-BOURNE_SHELL-definition phase.  Add
> fix-sysconfdir-and-localstatedir phase.  Adapt disable-broken-tests to 
> meson.
> [native-inputs]: Add python-docutils and rpcsvc-proto.
> * gnu/packages/patches/libvirt-create-machine-cgroup.patch: Delete.
> * gnu/packages/patches/libvirt-do-not-create-var-dirs.patch: New patch.
> * gnu/local.mk (dist_patch_DATA): Add new patch, remove the other.
>
> Signed-off-by: Ludovic Courtès 
>
> ```

Ooh no! Sorry for the breakage!

>
> Command to reproduce wrong:
> ```
> # This is wrong:
> # After commit
> luhux@thinkpad-x230 ~ [date: Thu 01 Apr 2021 09:16:37 PM HKT]
> $ GUIX_BUILD_OPTIONS="" guix time-machine 
> --commit=383b02a370252c08eb1d43ac94d659c1d3993a35 -c 8 -M 8 -- environment 
> --ad-hoc libvirt -- virsh connect
>  qemu:///system
> error: failed to connect to the hypervisor
> error: Failed to connect socket to 'var/run/libvirt/libvirt-sock': No such 
> file or directory
>
>
> ```
>
> It uses the wrong path to connect to libvirtd of the current system.

I see, I tried to cover all cases where libvirt would not use the
correct /var and /etc but clearly missed some :-/.

>
> Command to reproduce corrent:
> ```
> # This is corrent:
> # Before commit
>
>
> luhux@thinkpad-x230 ~ [date: Thu 01 Apr 2021 09:16:32 PM HKT]
> $ GUIX_BUILD_OPTIONS="" guix time-machine 
> --commit=c536f0b217714917988d2f412999d978c2f2f495 -c 8 -M 8 -- environment 
> --ad-hoc libvirt -- virsh connect qemu:///system
> error: failed to connect to the hypervisor
> error: Failed to connect socket to '/var/run/libvirt/libvirt-sock': No such 
> file or directory
> ```
>
> I use strace to create verbose log:
>
>
> ```
> luhux@thinkpad-x230 ~ [date: Thu 01 Apr 2021 09:22:18 PM HKT]
> $ GUIX_BUILD_OPTIONS="" guix time-machine 
> --commit=383b02a370252c08eb1d43ac94d659c1d3993a35 -c 8 -M 8 -- environment 
> --ad-hoc libvirt strace -- strace -o strace.log -- virsh connect 
> qemu:///system
> error: failed to connect to the hypervisor
> error: Failed to connect socket to 'var/run/libvirt/libvirt-sock': No such 
> file or directory
>
>
> ```
>
> strace shows that it did use the wrong path:
>
> ```
>   1056  access("var/run/libvirt/virtqemud-sock", F_OK) = -1 ENOENT (No such 
> file or directory)
>   1057  access("var/run/libvirt/libvirt-sock", F_OK) = -1 ENOENT (No such 
> file or directory)
> ```
>
> full strace log is in the attachment
>  | | |
>  V V V
>
>
> My guess is that the patch in the commit caused this problem, but I have no 
> ability to fix it.
> Please fix it

I'll see if I can look into it at the weekend, although I'm not sure
I'll be able to get to it, so in the meantime we should probably just
revert the updates. Thanks a lot for investigating though, I think we
ought to write a system test that uses virsh to connect if that's
possible.

All that being said, I just noticed somebody had already posted an
alternative patch to do the update before I did, maybe that one is
correct! https://issues.guix.gnu.org/46623

Anyways, I'll revert the patches tomorrow unless there are any
objections!

Sorry again,

Pierre


signature.asc
Description: PGP signature

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

[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,
/gnu/store/cydvkyxdkkg7k9n04miy238q8040c28q-guile-html-index-en.drv. The
build log contains this:

--
$ zcat 
/var/log/guix/drvs/cy/dvkyxdkkg7k9n04miy238q8040c28q-guile-html-index-en.drv.gz
Backtrace:
   4 (primitive-load "/gnu/store/g5xbrrd5llv5lpsgibqbwjymxjm?")
In ice-9/eval.scm:
619:8  3 (_ #f)
   191:27  2 (_ #f)
   223:20  1 (proc #)
In unknown file:
   0 (%resolve-variable (7 . %strict-tokenizer?) #)

ERROR: In procedure %resolve-variable:
Unbound variable: %strict-tokenizer?
--

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

[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
Description: PGP signature

bug#47545: Guix bug on guix pull

[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).

> ./guix/store.scm:1373:15: ERROR:
>   1. :
>   message: "some substitutes for the outputs of derivation 
> `/gnu/store/hnsk4qjsidn7xk6qb42sgy0ak2gbxbnb-zziplib-0.13.72.drv' failed 
> (usually happens due to networking issues); try `--fallback' to build 
> derivation from source "
>   status: 1
> guix pull: error: You found a bug: the program 
> '/gnu/store/bg6vs7ahglli408xaifp8rss68ss3qqc-compute-guix-derivation'
> failed to compute the derivation for Guix (version: 
> "a266c9fab88954b7c0fc0516e0a4c9834819dbc5"; system: "x86_64-linux";
> host version: "266d55dc3080475544bf45e72359c9b9bbcecd53"; pull-version: 1).

Seems like a bug with error reporting.  Also, from th ‘bad request line’ 
message,
this seems a bug in the substituter as well.

> Please report it by email to 
> 
> This has been happening for at least a few days on every `guix pull` 
> invokation.
> 
> Do I need to reinstall Guix?

No.  As a work-around, I recommend running guix pull with --fallback.  If that's
not sufficient, run guix pull with --no-substitutes.

Also, what's the last time the guix daemon was updated?  The substitution code
is ran from the daemon and there have been some fixes to the substitution code
lately.

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

bug#47545: Guix bug on guix pull

[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 channel:
  guix  https://git.savannah.gnu.org/git/guix.git   a266c9f
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
building /gnu/store/49vr6qfnjjwl3vk1cv91hzpxqm34j3xk-module-import.drv...
downloading from 
https://ci.guix.gnu.org/nar/zstd/zbwmal8kn6azc712ipwci8z2px19bfjn-module-import 
...
 module-import  2KiB

  91KiB/s 00:00 [##] 100.0%

downloading from 
https://ci.guix.gnu.org/nar/lzip/yg3ddx822nm7422a2v2yi0w5chhv41by-module-import-compiled
 ...
 module-import-compiled  1.5MiB 

 4.1MiB/s 00:00 [##] 100.0%

downloading from 
https://ci.guix.gnu.org/nar/lzip/9v4hg0g74bw7kn77r0ng9irfzxsgc07j-module-import-compiled
 ...
 module-import-compiled 

5.2MiB/s 00:00 | 1.9MiB transferred

building 
/gnu/store/jh38gf6fadq94rk9039jzc12anf75n5r-compute-guix-derivation.drv...
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
@ substituter-started 
/gnu/store/531rwkb8m6yccq4l1mkrqxclrqwy0jj3-git-minimal-2.31.1 substitute
@ download-started 
/gnu/store/531rwkb8m6yccq4l1mkrqxclrqwy0jj3-git-minimal-2.31.1 
https://ci.guix.gnu.org/nar/lzip/531rwkb8m6yccq4l1mkrqxclrqwy0jj3-git-minimal-2.31.1
 4325662
@ download-progress 
/gnu/store/531rwkb8m6yccq4l1mkrqxclrqwy0jj3-git-minimal-2.31.1 
https://ci.guix.gnu.org/nar/lzip/531rwkb8m6yccq4l1mkrqxclrqwy0jj3-git-minimal-2.31.1
 4325662 65546
-@ download-progress 
/gnu/store/531rwkb8m6yccq4l1mkrqxclrqwy0jj3-git-minimal-2.31.1 
https://ci.guix.gnu.org/nar/lzip/531rwkb8m6yccq4l1mkrqxclrqwy0jj3-git-minimal-2.31.1
 4325662 983072
@ download-progress 
/gnu/store/531rwkb8m6yccq4l1mkrqxclrqwy0jj3-git-minimal-2.31.1 
https://ci.guix.gnu.org/nar/lzip/531rwkb8m6yccq4l1mkrqxclrqwy0jj3-git-minimal-2.31.1
 4325662 1769519
@ download-progress 
/gnu/store/531rwkb8m6yccq4l1mkrqxclrqwy0jj3-git-minimal-2.31.1 
https://ci.guix.gnu.org/nar/lzip/531rwkb8m6yccq4l1mkrqxclrqwy0jj3-git-minimal-2.31.1
 4325662 2883652
@ download-progress 
/gnu/store/531rwkb8m6yccq4l1mkrqxclrqwy0jj3-git-minimal-2.31.1 
https://ci.guix.gnu.org/nar/lzip/531rwkb8m6yccq4l1mkrqxclrqwy0jj3-git-minimal-2.31.1
 4325662 3801177
@ download-progress 
/gnu/store/531rwkb8m6yccq4l1mkrqxclrqwy0jj3-git-minimal-2.31.1 
https://ci.guix.gnu.org/nar/lzip/531rwkb8m6yccq4l1mkrqxclrqwy0jj3-git-minimal-2.31.1
 4325662 4325662
@ download-succeeded 
/gnu/store/531rwkb8m6yccq4l1mkrqxclrqwy0jj3-git-minimal-2.31.1 
https://ci.guix.gnu.org/nar/lzip/531rwkb8m6yccq4l1mkrqxclrqwy0jj3-git-minimal-2.31.1
 4325662


@ substituter-succeeded 
/gnu/store/531rwkb8m6yccq4l1mkrqxclrqwy0jj3-git-minimal-2.31.1
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
@ substituter-started 
/gnu/store/7jsb7vff5494nd39mqj0ins5i992dm6i-guix-daemon-1.2.0-19.8f9052d 
substitute
@ download-started 
/gnu/store/7jsb7vff5494nd39mqj0ins5i992dm6i-guix-daemon-1.2.0-19.8f9052d 
https://ci.guix.gnu.org/nar/lzip/7jsb7vff5494nd39mqj0ins5i992dm6i-guix-daemon-1.2.0-19.8f9052d
 -
@ download-progress 
/gnu/store/7jsb7vff5494nd39mqj0ins5i992dm6i-guix-daemon-1.2.0-19.8f9052d 
https://ci.guix.gnu.org/nar/lzip/7jsb7vff5494nd39mqj0ins5i992dm6i-guix-daemon-1.2.0-19.8f9052d
 - 65546
@ download-progress 
/gnu/store/7jsb7vff5494nd39mqj0ins5i992dm6i-guix-daemon-1.2.0-19.8f9052d 
https://ci.guix.gnu.org/nar/lzip/7jsb7vff5494nd39mqj0ins5i992dm6i-guix-daemon-1.2.0-19.8f9052d
 - 290921
@ download-succeeded 
/gnu/store/7jsb7vff5494nd39mqj0ins5i992dm6i-guix-daemon-1.2.0-19.8f9052d 
https://ci.guix.gnu.org/nar/lzip/7jsb7vff5494nd39mqj0ins5i992dm6i-guix-daemon-1.2.0-19.8f9052d
 290921


@ substituter-succeeded 
/gnu/store/7jsb7vff5494nd39mqj0ins5i992dm6i-guix-daemon-1.2.0-19.8f9052d
@ substituter-started 
/gnu/store/7yb63ccdrskjv06l938f7iv88h4cav41-zziplib-0.13.72 substitute
Backtrace:
In guix/ui.scm:
  2164:12 19 (run-guix-command _ . _)
In guix/scripts/substitute.scm:
652:2 18 (guix-substitute . _)
In unknown file:
   

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

[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"

[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?

  Mark

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

[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 such.

This is much better indeed. Thank you.

On Debian espeak seems to be activated after loading ".emacs" file.
Here, the package spells out all configuration messages displayed on in
the minibuffer.

Regards,
-- 
Nicolas Goaziou

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

[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 would
to the UCS-4 rewriting “somehow”.

The other option, which might be easier, would be to arrange to not use
UCS-4 in the first place, by choosing a bytevector data type for string
literals known to contain a store reference.  It can be done if we know
where those references come from—e.g., they’re introduced by
‘substitute*’ on the source.

I hope this makes sense!

Ludo’.

bug#47451: Guix pull building lz4-1.9.3 fails

[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

[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 package.


signature.asc
Description: This is a digitally signed message part

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

[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 Guix,
ca. 9098745b181b3022587a35afd255f7ff1d41ac86.)

Running the command below from a Guix checkout, which authenticates 15+K
commits, isn’t enough to trigger it:

  guix git authenticate --cache-key=whatever \
"9edb3f66fd807b096b48283debdcddccfea34bad" \
"BBB0 2DDF 2CEA F6A8 0D1D E643 A2A0 6DF2 A33A 54FA"

So it might rather be ‘update-cached-checkout’ that triggers it.

If you experience it, please share the command line and command output!

Ludo’.

bug#47472: fe: hash mismatch

[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 /gnu/store/12qcph6m26hlbyydsnl0ibl656397fld-fe-2.0.tar.gz.drv...
>
> Starting download of /gnu/store/nmamm3hz4k3ln8876zdsnaaz2zr1amii-fe-2.0.tar.gz
> From http://www.moria.de/~michael/fe/fe-2.0.tar.gz...
> downloading from http://www.moria.de/~michael/fe/fe-2.0.tar.gz ...
>  fe-2.0.tar.gz  232KiB171KiB/s 00:01 [##] 
> 100.0%
> sha256 hash mismatch for
> /gnu/store/nmamm3hz4k3ln8876zdsnaaz2zr1amii-fe-2.0.tar.gz:
>   expected hash: 1hwws7si1752z6hp61zxznvgsb6846lp8zl1hn5ddhsbafwalwb9
>   actual hash:   10mk5wc3dsdp46b3hkjyd740gcdv6m1gvlr3p8xjxf55b3vfs0la
> hash mismatch for store item
> '/gnu/store/nmamm3hz4k3ln8876zdsnaaz2zr1amii-fe-2.0.tar.gz'
> build of /gnu/store/12qcph6m26hlbyydsnl0ibl656397fld-fe-2.0.tar.gz.drv failed
> View build log at
> '/var/log/guix/drvs/12/qcph6m26hlbyydsnl0ibl656397fld-fe-2.0.tar.gz.drv.bz2'.
> guix build: error: build of
> `/gnu/store/12qcph6m26hlbyydsnl0ibl656397fld-fe-2.0.tar.gz.drv' failed
> --8<---cut here---end--->8---
>
> It is probably an upstream in-place replacement.

You're right. Upstream rebased 2.0 on top of 1.9 release.

I updated the hash. Thank you for the heads up.

Regards,
-- 
Nicolas Goaziou

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

[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 bounds write sounds like it could have dangerous consequences,
not sure how likely is "size_hint provides certain anomalous data"
though.


signature.asc
Description: This is a digitally signed message part

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

[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 system availability.

Fix: 
https://github.com/AcademySoftwareFoundation/openexr/commit/d80f11f4f55100d007ae80a162bf257ec291612c

CVE-2021-3478   31.03.21 16:15
There's a flaw in OpenEXR's scanline input file functionality in versions 
before 3.0.0-beta. An attacker able to submit a crafted file to be processed by 
OpenEXR could consume excessive system memory. The greatest impact of this flaw 
is to system availability.

Fix (? as Red Hat analyst points out in 
https://bugzilla.redhat.com/show_bug.cgi?id=1939160#c3, it indeed looks
uncertain): 
https://github.com/AcademySoftwareFoundation/openexr/commit/bc88cdb6c97fbf5bc5d11ad8ca55306da931283a


CVE-2021-3477   31.03.21 16:15
There's a flaw in OpenEXR's deep tile sample size calculations in
versions before 3.0.0-beta. An attacker who is able to submit a crafted
file to be processed by OpenEXR could trigger an integer overflow,
subsequently leading to an out-of-bounds read. The greatest risk of
this flaw is to application availability.

Fix (? as Red Hat analyst points out in 
https://bugzilla.redhat.com/show_bug.cgi?id=1939159#c3, it indeed looks
uncertain): 
https://github.com/AcademySoftwareFoundation/openexr/commit/467be80b75642efbbe6bdace558079f68c16acb1


signature.asc
Description: This is a digitally signed message part

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

[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 its raw build output (what we see in the snippet above);
>
>   3. the parent process reads that and sends it to its own
>  (current-build-output-port); that port processes those “@” build
>  traces according to the current ‘--verbosity’—see (guix status).
>
> With this in place, builds or downloads triggered during the evaluation
> of ‘compute-guix-derivation’ are reported in a consistent way from a UI
> viewpoint.
>
> There was one remaining glitch: the spinner that
> ‘compute-guix-derivation’ prints would show up in the middle of the
> prettified build output.  The second patch addresses that.

Pushed as a81a19930b2cbe1327e1e82d6210f80846ce2898.

Ludo’.

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

[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, that's to be expected:

Return a package matching SPEC.  SPEC may be a package name, or a
package name followed by an at-sign and a version number.  If the 
version number is not present, return the preferred newest version.

> (specification->package+output "qemu:doc") ; works as expected
In other words, use specification->package+output ;)

Regards,
Leo

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

[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 links to the required Lisp
> dependencies in '/gnu/store/...', so there should not be missing
> references.

Right.

The only case where there could be a missing reference is if the source
code contains an FFI reference stored in non-ASCII / UTF-8.

So we need to parse other encodings too as Mark suggested if I
understand correctly.

> I just wondered: does the grafting code take '.fasl' files into
> consideration?
> If yes, I guess a Lisp library could also end up in a strange
> half-grafted state if the grafting code modifies ASCII references and
> not UTF-32 ones...

Absolutely, .fasls suffer from the same problem since they may encode
strings as UTF-32.

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

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

[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"

[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 to get the full list of
>> store refrences.
>
> I don't think there is need to scan recursively: if package A depends on
> B which depends on C, then A can lists the dependency on B in a file,
> and B can do the same for C.  This way the relationship between A and C
> is properly stored.
>
> Am I missing something?

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 links to the required Lisp
dependencies in '/gnu/store/...', so there should not be missing
references.


>> And as Mark wrote below, with the current grafting code, this list of
>> store references will not solve grafting for paths that are in UTF-32 or
>> both in ASCII and UTF-32 in the binary file.
>
> Indeed, and that's the core of the issue here I believe, since grafting
> is what breaks Nyxt in practice.
>
> Cheers!

I just wondered: does the grafting code take '.fasl' files into
consideration?
If yes, I guess a Lisp library could also end up in a strange
half-grafted state if the grafting code modifies ASCII references and
not UTF-32 ones...


signature.asc
Description: PGP signature

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

[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 refrences.

I don't think there is need to scan recursively: if package A depends on
B which depends on C, then A can lists the dependency on B in a file,
and B can do the same for C.  This way the relationship between A and C
is properly stored.

Am I missing something?

> And as Mark wrote below, with the current grafting code, this list of
> store references will not solve grafting for paths that are in UTF-32 or
> both in ASCII and UTF-32 in the binary file.

Indeed, and that's the core of the issue here I believe, since grafting
is what breaks Nyxt in practice.

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

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

[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 encoding might
> be enough.  But of course this is less general and more brittle.

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 refrences.
And as Mark wrote below, with the current grafting code, this list of
store references will not solve grafting for paths that are in UTF-32 or
both in ASCII and UTF-32 in the binary file.


Ludovic Courtès  skribis:

> 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 this
>> thread .  I wrote:
>>
>>   If you don't want to change the daemon, it could be worked around in our
>>   build-side code as follows: we could add a new phase to certain build
>>   systems (or possibly gnu-build-system) that scans each output for
>>   UTF-16/32 encoded store references that are never referenced in UTF-8.
>>   If such references exist, a file with an unobtrusive name would be added
>>   to that output containing those references encoded in UTF-8.  This would
>>   enable our daemon's existing reference scanner to find all of the
>>   references.
>>
>>   Our grafting code would then need to be extended to recognize and
>>   transform store references encoded in UTF-16/32 as well as UTF-8.
>
> Oh thanks for the reminder.
>
> The separate ASCII file doesn’t solve it all because, as you write, we’d
> need to change the grafting code as well.
>
> Then it might be simpler to use a “byte vector” data type for those
> strings.  We’ll have to wait for Pierre’s patches to get a better idea.
> :-)

I'm not sure what you mean with the "byte vector" data type here. Could
you explain what you're thinking about with a few more details?


signature.asc
Description: PGP signature

bug#47028: Discourage single-character package names

[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 out!

T G-R

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

[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"

[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 in this
> thread .  I wrote:
>
>   If you don't want to change the daemon, it could be worked around in our
>   build-side code as follows: we could add a new phase to certain build
>   systems (or possibly gnu-build-system) that scans each output for
>   UTF-16/32 encoded store references that are never referenced in UTF-8.
>   If such references exist, a file with an unobtrusive name would be added
>   to that output containing those references encoded in UTF-8.  This would
>   enable our daemon's existing reference scanner to find all of the
>   references.
>
>   Our grafting code would then need to be extended to recognize and
>   transform store references encoded in UTF-16/32 as well as UTF-8.

Oh thanks for the reminder.

The separate ASCII file doesn’t solve it all because, as you write, we’d
need to change the grafting code as well.

Then it might be simpler to use a “byte vector” data type for those
strings.  We’ll have to wait for Pierre’s patches to get a better idea.
:-)

Thanks,
Ludo’.

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

[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"

[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 files without having to deal with their encoding might
be enough.  But of course this is less general and more brittle.

Mark, Guillaume, would you have time to give this a try?
I'm a bit busy at the moment.  Let me know if you can't work on it, I'll
try to find time to work on a patch.

Cheers!

--
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

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

[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 .  I wrote:

  If you don't want to change the daemon, it could be worked around in our
  build-side code as follows: we could add a new phase to certain build
  systems (or possibly gnu-build-system) that scans each output for
  UTF-16/32 encoded store references that are never referenced in UTF-8.
  If such references exist, a file with an unobtrusive name would be added
  to that output containing those references encoded in UTF-8.  This would
  enable our daemon's existing reference scanner to find all of the
  references.

  Our grafting code would then need to be extended to recognize and
  transform store references encoded in UTF-16/32 as well as UTF-8.

  Mark