bug#56088: Emacs Elfeed does not display non English characters
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
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
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
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
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’
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
