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

[Kei]

Hi there!

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.

Kei
From fcb7feadbd497e5d64c7867410bba894b277661f Mon Sep 17 00:00:00 2001
From: Kei Kebreau 
Date: Sun, 28 Mar 2021 22:38:09 -0400
Subject: [PATCH] gnu: emacspeak: Fix Tclx and espeak server loading.

Fixes .

* gnu/packages/emacs-xyz.scm (emacspeak)[arguments]: In the 'configure' phase,
add Tclx library to the load path of Tcl in the espeak server script.  Remove
'wrap-program' phase.
---
 gnu/packages/emacs-xyz.scm | 25 -
 1 file changed, 12 insertions(+), 13 deletions(-)

diff --git a/gnu/packages/emacs-xyz.scm b/gnu/packages/emacs-xyz.scm
index ead2144b42..764a1cd99c 100644
--- a/gnu/packages/emacs-xyz.scm
+++ b/gnu/packages/emacs-xyz.scm
@@ -11987,8 +11987,18 @@ highlights quasi-quoted expressions.")
#:phases
(modify-phases %standard-phases
  (replace 'configure
-   (lambda _
+   (lambda* (#:key inputs outputs #:allow-other-keys)
  (setenv "SHELL" (which "sh"))
+ ;; Ensure the tclespeak.so binary is found in the correct location
+ ;; by adding the path to the Tclx library to the Tcl $auto_path
+ ;; variable.
+ (with-fluids ((%default-port-encoding "ISO-8859-1"))
+   (substitute* "servers/espeak"
+ (("package require Tclx")
+  (string-append "set auto_path [linsert $auto_path 0 "
+ (assoc-ref inputs "tclx")
+ "/lib]\n"
+ "package require Tclx"
  ;; Configure Emacspeak according to etc/install.org.
  (invoke "make" "config")))
  (add-after 'build 'build-espeak
@@ -12016,18 +12026,7 @@ highlights quasi-quoted expressions.")
;; Install the convenient startup script.
(mkdir-p bin)
(copy-file "run" (string-append bin "/emacspeak")))
- #t))
- (add-after 'install 'wrap-program
-   (lambda* (#:key inputs outputs #:allow-other-keys)
- (let* ((out (assoc-ref outputs "out"))
-(emacspeak (string-append out "/bin/emacspeak"))
-(espeak (string-append (assoc-ref inputs "espeak")
-   "/bin/espeak")))
-   ;; The environment variable DTK_PROGRAM tells emacspeak what
-   ;; program to use for speech.
-   (wrap-program emacspeak
- `("DTK_PROGRAM" ":" prefix (,espeak)))
-   #t
+ #t)))
#:tests? #f)); no check target
 (inputs
  `(("emacs" ,emacs)
-- 
2.31.0

bug#47458: Terrible UX upgrading Emacs in Guix

[Mark H Weaver]

I just updated my Guix system, which included the Emacs update from 27.1
to 27.2.  After "guix package -m mhw-manifest.scm" finished running
(which takes a long time for me, since I don't use substitutes), and
before I even noticed that it had finished, my existing Emacs session
started misbehaving badly.

It failed to even open a plain text file in fundamental mode (a .drv
file) with an inscrutible error about 'arrayp'.  I tried to enable the
debugger with M-x toggle-debug-on-error, but then I started getting
errors about 'debug' not found.  (I neglected to record the exact
messages).

I tried running "emacs -Q", and the same errors happened there too.  I
tried running "emacs -Q" from my root shell on a Linux text terminal,
and the same errors happened there.

I resorted to using 'vi' (which thankfully I had, and still remember how
to use for basic editing) to revert the emacs update on my private
branch and to rebuild my user profiles.

Eventually, I realized what the problem was:

(1) My existing emacs session started failing because
~/.guix-profile/share/emacs/27.1 had disappeared out from under it.

(2) My newly launched emacs sessions were failing because my
EMACSLOADPATH variable was still set to its old value, pointing at
/home/mhw/.guix-profile/share/emacs/27.1/lisp, which no longer
existed.

I'm not sure why I've never run into this problem before.  I'm also not
sure what can be done to make this better, but if anyone has ideas, that
would be good.  If a 7+ year Guix veteran developer gets bitten badly by
this, I doubt that less experienced users will be impressed.

Any ideas?

   Mark

bug#47442: guix system delete-generations does not use bootloader configuration

[raid5atemyhomework via Bug reports for GNU Guix]

Note as well that keyboard layouts at Grub time are also broken by this.  As 
the keyboard layout is used when accepting passphrases for cryptodisks, this 
can leave a user potentially unable to boot at all without expert GRUB 
knowledge, if they selected a passphrase including characters not available on 
default US keyboard.


An alternative solution is to split the `grub.cfg` file into two pieces: one 
containing the bootloader configuration settings, the other containing the 
entries.  Then `reinstall-bootloader` just changes the entries.

On alternative bootloaders, there is usually little to no configuration.

* `depthcharge` - No configuration.
* `extlinux` - Only `timeout` configuration.
* `u-boot` - Based on `extlinux` (so only `timeout` configuration).

So a possible design would be to have a "split" generation of the configuration 
file.

This affects how `bootloader-configuration-file-generator` is used, however.  
This affects three points:

* `gnu/machine/ssh.scm` - This is given a `bootloader-configuration` from the 
actual OS on the machine, so probably OK to use this legacy interface.
* `gnu/system.scm` - Like the above, given a `bootloader-configuration` from 
the actual OS on the machine.
* `gnu/scripts/system.scm` - This is the problem point identified before.


Yet another solution would be to augment `boot-parameters` with the fields of 
`bootloader-configuration`, but that violates DRY --- fields added to 
`bootloader-configuration` in the future need to be added to `boot-parameters` 
as well, so I think this is undesirable.


Thanks
raid5atemyhomework

bug#47451: Guix pull building lz4-1.9.3 fails

[Leo Famulari]

On Sun, Mar 28, 2021 at 09:43:53AM -0400, Bone Baboon via Bug reports for GNU 
Guix wrote:
> Error Message:
[...]
> @ build-log 28219 16
> # Test for #596
> @ build-log 28219 32
> ../programs/lz4 -m tmp-tlb-test
> @ build-log 28219 47
> ../programs/lz4 tmp-tlb-test.lz4 tmp-tlb-test2
> @ build-log 28219 121
> tmp-tlb-test.lz4 : decoded 5 bytes
>  
> @ build-log 28219 35
> diff -q tmp-tlb-test tmp-tlb-test2
> @ build-log 28219 74
> make[1]: Leaving directory '/tmp/guix-build-lz4-1.9.3.drv-0/source/tests'
> @ build-log 28219 39
> make: *** [Makefile:127: test] Error 2
> @ build-log 28219 34
> 
> Test suite failed, dumping logs.
> @ build-log 28219 124
> command "make" "test" "-j" "8" "CC=gcc" 
> "prefix=/gnu/store/y6j2zpdpyw5xdnfspyjqgmbq1p7k22bx-lz4-1.9.3" failed with 
> status 2
> builder for `/gnu/store/8r1d8lw4xix0r90irz0rr1gnnq4mainz-lz4-1.9.3.drv' 
> failed with exit code 1
> @ build-failed /gnu/store/8r1d8lw4xix0r90irz0rr1gnnq4mainz-lz4-1.9.3.drv - 1 
> builder for `/gnu/store/8r1d8lw4xix0r90irz0rr1gnnq4mainz-lz4-1.9.3.drv' 
> failed with exit code 1

I think this bug was fixed in Guix in February:

https://git.savannah.gnu.org/cgit/guix.git/commit/?id=78bbf6c44394c1024e0a369d0d5947e669606248

If I understand correctly, you're trying to use Guix from May 2020.

I recommend trying again but with "--cores=1" [0]. The lz4 test suite may
not support multithreaded execution reliably:

https://github.com/lz4/lz4/issues/957

You can limit the use of a single thread by only building this lz4
derivation with --cores=1:

`guix build /gnu/store/8r1d8lw4xix0r90irz0rr1gnnq4mainz-lz4-1.9.3.drv --cores=1`

[0]
https://guix.gnu.org/manual/en/html_node/Common-Build-Options.html

bug#47375: guix test failure: tests/print

[Léo Le Bouter via Bug reports for GNU Guix]

On Sun, 2021-03-28 at 18:25 +0200, Ludovic Courtès wrote:
> When updating the ‘guix’ package, what you need to run is:
> 
>   ./pre-inst-env guix build guix
> 
> It’s similar to other packages.
> 
> In general, we update it when there are changes to the daemon and its
> helper programs (‘guix substitute’, etc.).  These are pretty much the
> only reasons to update it.

Thanks will make sure to do that. I was a bit tired and I think I
misunderstood something in a discussion with Lfam on IRC that made me
only run 'guix pull' and restart guix-daemon.

Note, the reason I upgraded the 'guix' package here was to fix 'guix
pull' from older installations on powerpc64le-linux machines of mine.

Léo


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

bug#47375: guix test failure: tests/print

[Ludovic Courtès]

Hi,

Léo Le Bouter  skribis:

> On Fri, 2021-03-26 at 00:24 +0100, Ludovic Courtès wrote:
>> Léo Le Bouter  skribis:
>> 
>> > Full log: https://ci.guix.gnu.org/build/117996/log/raw
>> 
>> Speaking of which: please always build packages before pushing.  :-)
>> 
>> Thanks,
>> Ludo’.
>
> I ran 'guix pull' but turns out that wasnt sufficient.

When updating the ‘guix’ package, what you need to run is:

  ./pre-inst-env guix build guix

It’s similar to other packages.

In general, we update it when there are changes to the daemon and its
helper programs (‘guix substitute’, etc.).  These are pretty much the
only reasons to update it.

HTH!

Ludo’.

bug#47453: nyxt browser crashes when right click

[Enrico Schwass via Bug reports for GNU Guix]

latest guix latest nyxt browser x86-64

bug#47451: Guix pull building lz4-1.9.3 fails

[Bone Baboon via Bug reports for GNU Guix]

I am getting an error message that tells me to report it to this Guix
bug mailing list.

After reading the Specifying Additional Channels section of the Guix
manual I created  `~/.config/guix/channels.scm` with these contents: 

```
(cons
 (channel
  (name 'openvpn-2-4-9)
  (url "https://git.savannah.gnu.org/git/guix.git;)
;  (commit "33c140e0fb3ddcd6ce05c02bc00df102830ecbd6"))
  (commit "c5a2b70135c9830e9c3051ddf4a096f9a80eb952"))
 %default-channels)

```

When I run `guix pull --no-substitutes` I get this error message below.

I get the same error message if I use commit
c5a2b70135c9830e9c3051ddf4a096f9a80eb952 and run `guix pull
--no-substitutes`.

When I run `guix describe` on the computer that is getting this error it
outputs:
```
Generation 5Mar 26 2021 22:04:40(current)
  guix 53dd99b
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 53dd99bc0b2e23c5463b4cb95546fd438a72d229
```

With the same channels.scm file with the
33c140e0fb3ddcd6ce05c02bc00df102830ecbd6 commit on another x86_64
computer if I run `guix pull` there is no error message.

Error Message:

```
...

@ build-log 28219 16
# Test for #596
@ build-log 28219 32
../programs/lz4 -m tmp-tlb-test
@ build-log 28219 47
../programs/lz4 tmp-tlb-test.lz4 tmp-tlb-test2
@ build-log 28219 121
tmp-tlb-test.lz4 : decoded 5 bytes 
@ build-log 28219 35
diff -q tmp-tlb-test tmp-tlb-test2
@ build-log 28219 74
make[1]: Leaving directory '/tmp/guix-build-lz4-1.9.3.drv-0/source/tests'
@ build-log 28219 39
make: *** [Makefile:127: test] Error 2
@ build-log 28219 34

Test suite failed, dumping logs.
@ build-log 28219 124
command "make" "test" "-j" "8" "CC=gcc" 
"prefix=/gnu/store/y6j2zpdpyw5xdnfspyjqgmbq1p7k22bx-lz4-1.9.3" failed with 
status 2
builder for `/gnu/store/8r1d8lw4xix0r90irz0rr1gnnq4mainz-lz4-1.9.3.drv' failed 
with exit code 1
@ build-failed /gnu/store/8r1d8lw4xix0r90irz0rr1gnnq4mainz-lz4-1.9.3.drv - 1 
builder for `/gnu/store/8r1d8lw4xix0r90irz0rr1gnnq4mainz-lz4-1.9.3.drv' failed 
with exit code 1
cannot build derivation 
`/gnu/store/pd0m0qikzva35hi8l1lcciiw9l1fsx6p-subversion-1.14.0.drv': 1 
dependencies couldn't be built
Backtrace:
  11 (primitive-load 
"/gnu/store/6ck8lnf8jdycbcfpp2g8af559zjb6ffg-compute-guix-derivation")
In ice-9/eval.scm:
155:9 10 (_ _)
159:9  9 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(# 
?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
In ./guix/store.scm:
  2049:24  8 (run-with-store # _ 
#:guile-for-build _ #:system _ #:target _)
   1883:8  7 (_ _)
In ./guix/gexp.scm:
   258:18  6 (_ _)
   1123:2  5 (_ _)
982:2  4 (_ _)
843:4  3 (_ _)
In ./guix/store.scm:
  1931:12  2 (_ #)
   1358:5  1 (map/accumulate-builds # _ _)
  1369:15  0 (_ # _ _)

./guix/store.scm:1369:15: ERROR:
  1. :
  message: "build of 
`/gnu/store/pd0m0qikzva35hi8l1lcciiw9l1fsx6p-subversion-1.14.0.drv' failed"
  status: 100
guix pull: error: You found a bug: the program 
'/gnu/store/6ck8lnf8jdycbcfpp2g8af559zjb6ffg-compute-guix-derivation'
failed to compute the derivation for Guix (version: 
"33c140e0fb3ddcd6ce05c02bc00df102830ecbd6"; system: "x86_64-linux";
host version: "53dd99bc0b2e23c5463b4cb95546fd438a72d229"; pull-version: 1).
Please report it by email to .
```

bug#47448: lualatex doesn't find libzzip-0.so.13 (easy bug?)

[Sergiu Ivanov]

Hello Andreas,

Thus quoth  Andreas Enge  on Sun Mar 28 2021 at 12:29 (+0200):
> Hello Sergiu,
>
> Am Sat, Mar 27, 2021 at 08:22:30PM +0100 schrieb Sergiu Ivanov:
>> I have trouble running lualatex from the TeX Live distribution (package
>> texlive) :
>> $ lualatex
>> /home/scolobb/.guix-profile/bin/lualatex: error while loading shared 
>> libraries: libzzip-0.so.13: cannot open shared object file: No such file or 
>> directory
>
> I confirm the bug, and am forwarding it to the bugtracker.

Thank you!

> lualatex is a wrapped binary, and the following shows the problem:
> $ ldd $(guix build texlive-bin)/bin/luatex
> ...
>   libzzip-0.so.13 => not found
>
>> I installed the zziplib package which brings in libzzip.so.13, but not
>> libzzip-0.so.13.
>
> Indeed this seems to be the problem, and I suspect it is happening in the
> zziplib package. Its version is 0.13.72, but the soname versions are
> 13.0.72, which already suggests that there is some
> confusion happening.

Ah, I didn't even think to check the zziplib package.

> Regardless, part of the version number should not appear before the "so"
> in libzzip-0.so.13.

Yeah, that looks weird indeed.

> Hm, the following looks correct, issued from a profile containing zziplib:
> $ pkg-config --libs zziplib
> -L/gnu/store/fx0cdzzppd8jc09sianbq6gl1h7mxx3x-zziplib-0.13.72/lib 
> -L/gnu/store/rykm237xkmq7rl1p0nwass01p090p88x-zlib-1.2.11/lib -lzzip -lz
>
> So it might be a problem with texlive-bin instead.

Oh, thank you for these ideas!

TeX Live packages kind of scare me a little, because they tend to be
complex (at least from my modest Nix experience).  I do plan to do some
small contributions to Guix packages soon, which should get me started
with the workflow, and help me fix such issues directly in the future.

-
Sergiu

bug#47448: lualatex doesn't find libzzip-0.so.13 (easy bug?)

[Andreas Enge]

Hello Sergiu,

Am Sat, Mar 27, 2021 at 08:22:30PM +0100 schrieb Sergiu Ivanov:
> I have trouble running lualatex from the TeX Live distribution (package
> texlive) :
> $ lualatex
> /home/scolobb/.guix-profile/bin/lualatex: error while loading shared 
> libraries: libzzip-0.so.13: cannot open shared object file: No such file or 
> directory

I confirm the bug, and am forwarding it to the bugtracker.
lualatex is a wrapped binary, and the following shows the problem:
$ ldd $(guix build texlive-bin)/bin/luatex
...
libzzip-0.so.13 => not found

> I installed the zziplib package which brings in libzzip.so.13, but not
> libzzip-0.so.13.

Indeed this seems to be the problem, and I suspect it is happening in the
zziplib package. Its version is 0.13.72, but the soname versions are
13.0.72, which already suggests that there is some confusion happening.
Regardless, part of the version number should not appear before the "so"
in libzzip-0.so.13.

Hm, the following looks correct, issued from a profile containing zziplib:
$ pkg-config --libs zziplib
-L/gnu/store/fx0cdzzppd8jc09sianbq6gl1h7mxx3x-zziplib-0.13.72/lib 
-L/gnu/store/rykm237xkmq7rl1p0nwass01p090p88x-zlib-1.2.11/lib -lzzip -lz

So it might be a problem with texlive-bin instead.

Andreas