bug#56088: Emacs Elfeed does not display non English characters

2023-07-19 Thread Oleg Pykhalov
Oleg Pykhalov  writes:

> After ‘guix pull’ from 0c5299200ffcd16370f047b7ccb187c60f30da34 to
> 85d7ad2be89b4a93e23b2e5715f90a682c34c09d Elfeed in Emacs does not
> display non English characters.  See the screenshot.

It seems that the issue is not specific to Emacs packaged in Guix.

https://github.com/skeeto/elfeed/issues/437 partially solves the issue:

> Somehow, calling M-x toggle-enable-multibyte-characters twice fixes
> the multibyte character display.
>
> Any ideas to what might cause this or how to debug this? E.g. what
> functions to step through, what variables and environment variables to
> check?  System and version information
>
> I use the latest elfeed commit 243add9 with (setq elfeed-use-curl
> t). Also as seen in the screenshot, I use elfeed-goodies, but
> disabling it doesn't fix the problem, so it's not the cause.
>
> I use the master of the pure-gtk emacs fork with native-compile,
> runnin M-X emacs-version prints
>
> GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.30,
> cairo version 1.17.4) of 2021-08-09
>
> I'm on Archlinux and have some locale settings which are a mixture of
> english and german for different LC_... variables, but launching emacs
> with LC_ALL=C also didn't fix this issue.  @meliache Author meliache
> commented Aug 23, 2021
>
> ...
>
> Oh, okay, it was an issue with my personal locale or language
> environment, something that apparently wasn't fixed by launching emacs
> with LC_ALL=C. But adding the line
>
> (set-language-environment "utf-8")
>
> to my init fixed this somehow man_shrugging

Apologies for the noise, closing the issue.

Oleg.


signature.asc
Description: PGP signature


bug#64736: pipewire doesn't provide libspa-libcamera.so

2023-07-19 Thread Alexandre Hannud Abdo

Ni! File `usr/lib/spa-0.2/libcamera/libspa-libcamera.so` isn't found when 
installing pipewire.

This seems to affect screen sharing on wayland through wireplumber, or at least 
my setup broke once the messages below started appearing:

```

M 22:57:06.048626  wp-device 
../source/lib/wp/device.c:619:wp_spa_device_new_from_spa_factory: SPA handle 
'api.libcamera.enum.manager' could not be loaded; is it installed?
M 22:57:06.048653   script/libcamera libcamera.lua:173:chunk: PipeWire's 
libcamera SPA missing or broken. libcamera not supported.

```

Cheers, ale



OpenPGP_0x722BE2E50CE6A56B.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


bug#64734: Recursive hackage import fails

2023-07-19 Thread Saku Laesvuori via Bug reports for GNU Guix
Importing hackage packages recursively fails with similar error to this:

```
$ guix import hackage linear-generics --recursive
Backtrace:
  11 (primitive-load "/home/saku/.config/guix/current/bin/gu…")
In guix/ui.scm:
   2309:7 10 (run-guix . _)
  2272:10  9 (run-guix-command _ . _)
In guix/scripts/import.scm:
90:11  8 (guix-import . _)
In guix/scripts/import/hackage.scm:
   129:26  7 (guix-import-hackage . _)
In guix/import/utils.scm:
651:3  6 (recursive-import _ #:repo->guix-package _ #:guix-name . #)
   613:31  5 (topological-sort _ # …)
   655:29  4 (_ _)
In unknown file:
   3 (remove # …)
In guix/import/utils.scm:
   635:39  2 (exists? #< name: "th-abstraction" dow…> …)
In guix/import/hackage.scm:
128:6  1 (hackage-name->package-name #< name: "t…>)
In unknown file:
   0 (string-prefix? "ghc-" #< name: "th-ab…> …)

ERROR: In procedure string-prefix?:
In procedure string-prefix?: Wrong type argument in position 2 (expecting 
string): #< name: "th-abstraction" downstream-name: 
"ghc-th-abstraction" type: regular min-version: any max-version: any>

```

I tried to find out what passes the `upstream-input` to
`hackage-name->package-name`, but only found out with `pk` that it seems
to only happen with the recursed dependencies and not with the root
package. I also tried to make `hackage-name->package-name` accept
`upstream-input` records but that a new error, so I assume the issue is
that something in the importer is returning `upstream-input` records
when it should return package names.

I could try to debug this further but I don't feel like I know enough
about debugging with guile nor about debugging scheme.


signature.asc
Description: PGP signature


bug#64729: xelatex is broken, because xelatex.fmt is missing

2023-07-19 Thread Ricardo Wurmus
Since the merge of the tex-team-next branch earlier this week xelatex is
broken.  I tried installing different collection packages, but I cannot
find any package providing the xelatex.fmt file.

This also affects packages like python-nbconvert, which now has a
failing test suite as it can no longer build PDFs with xelatex.

--
Ricardo





bug#64302: Guix derivation cannot be computed during pull

2023-07-19 Thread Andreas Enge
Hello,

Am Mon, Jul 10, 2023 at 11:38:47PM +0200 schrieb Ludovic Courtès:
> Is there any more data you can grab?  Perhaps in
> /var/log/guix-daemon.log or similar if that’s on a foreign distro?

it is a GNU system virtual machine. And I have this in /var/log/messages:

Jul 19 11:57:51 localhost vmunix: [4619013.095327] 
oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/,task=69h614ii57kpgn5,pid=16408,uid=1000
Jul 19 11:57:51 localhost vmunix: [4619013.095350] Out of memory: Killed 
process 16408 (69h614ii57kpgn5) total-vm:54kB, anon-rss:433096kB, 
file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:952kB oom_score_adj:0

> And as a last resort, ‘strace -f -o /tmp/log -s 500 guix pull’, so we
> can get an idea of what happens.

While this appears in the strace log:

16408 +++ killed by SIGKILL +++

So we have the culprit; not a Guix bug per se.

$ cat /proc/meminfo 
MemTotal: 997864 kB
MemFree:  679044 kB
MemAvailable: 817052 kB

It looks like 1GB of memory is not enough for "guix pull", which is
not nice. Has this been addressed in later commits? Is there a known
lower memory limit for using Guix?

Andreas






bug#64593: ‘guix system image’ fails to create image while invoking ‘grub-bios-setup’

2023-07-19 Thread Josselin Poiret via Bug reports for GNU Guix
Hi Sergey,

Sergey Trofimov  writes:

> shouldn't it be `(bootloader grub-efi-bootloader)` if you're 
> building a `efi-raw` image?
> With efi grub it builds and boots just fine, as I've tested before 
> submitting the patch.

I think I agree with you that you should expect efi images to use efi
bootloaders.  The efi-raw image name is a bit misleading I would argue,
since the image type doesn't decide what bootloader is used, and using a
BIOS bootloader with an efi image seems a bit weird.  The fact that it's
used as the default image type is a bit troubling though, so we could
add a new default image type that uses MBR, so that BIOS bootloaders
work with it.

WDYT Ludo?

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature