bug#41132: [core-updates]: Fonts not working on foreign distro (Debian)

For the sake of trying something, I'm going to try patching fontconfig with this patch that other distros (Debian and Arch) are using: https://salsa.debian.org/freedesktop-team/fontconfig/-/blob/master/debian/patches/do_not_remove_uuid.patch I don't know how fontconfig works but that patch fixed

bug#41132: [core-updates]: Fonts not working on foreign distro (Debian)

On Fri, May 08, 2020 at 03:08:53AM +0200, Tobias Geerinckx-Rice wrote: > > /var/cache/fontconfig: not cleaning unwritable cache directory > > This is certainly a classic. Have you tried deleting this stale directory? > Guix System does so for you, I suppose Debian does not. It doesn't jive > wit

bug#41132: [core-updates]: Fonts not working on foreign distro (Debian)

Leo, Leo Famulari 写道： I tried `fc-cache -rv`. Using Debian's fc-cache, it looks like this: [...] /var/cache/fontconfig: not cleaning unwritable cache directory And with Guix's fc-cache: [...] /var/cache/fontconfig: not cleaning unwritable cache directory This is certainly a classic. Ha

bug#41132: [core-updates]: Fonts not working on foreign distro (Debian)

I'm having trouble with Guix packages using fonts from my Debian 10 system after a core-updates merge. Using Inkscape from core-updates, the text I put in my SVG files fails to display. When I look at the Inkscape 'Text and Font' tool, it shows my chosen font with a red line through it, as though

bug#41115: warsow-qfusion bundles compiled software, third party sources

Thanks. Closing. -- Ricardo

bug#39894: [Common Lisp] asdf-build-system/source should refer to dependencies in the store

I made a mistaken in the original post: the cl-* (source) packages do propagate their input. So source packages _do_ work as expected. What we'd like to do improve here is _not_ propagate the inputs and instead refer directly to them in the store. I tried generating and .asd which would do the

bug#41123: shepherd exits for no good reason

Hey Ludo, > May 7 09:36:52 localhost shepherd[1]: Exiting shepherd... > May 7 09:36:52 localhost shepherd[1]: Service xorg-server has been stopped. > May 7 09:36:52 localhost shepherd[1]: Service console-font-tty2 has been > stopped. > May 7 09:36:52 localhost shepherd[1]: Service term-t

bug#40981: Graphical installer tests sometimes hang.

Hello, The previous patch was not working. The reason is that, when a process is forked and before execv is called, it shares the parent signal handler. So when sending a SIGTERM to the child process, we are stopping root-service, if the signal is received before the child has forked. The work-

bug#41116: Guix deploy fails with new version of Herd

Hi Marius, Marius Bakke writes: > Hi Alex, > > [...] > > This issue has been reported by a number of users on IRC. I think the > problem is that the the #:file-creation-mask keyword requires support > from the running Shepherd, which may not have it yet. I think we should > revert commit 4c0cc

bug#41120: uvesafb service is unsupported on aarch64

On Thu, May 07, 2020 at 04:55:13PM +0200, pelzflorian (Florian Pelz) wrote: > I have more success with moving the file-exists check into the > #~(lambda …) like the attached patch. Sorry I forgot to git add. This is the patch. >From f88b1b487d48c959a7ed00d6032ccfe05aa81f0e Mon Sep 17 00:00:00 200

bug#41120: uvesafb service is unsupported on aarch64

On Thu, May 07, 2020 at 11:12:34AM +0300, Efraim Flashner wrote: > I haven't tested the produced image, but the following builds without > trying to also build v86d > > (start >(if (and (and (string-suffix? "linux-gnu" %host-type) > (or (string-prefix?

bug#41116: Guix deploy fails with new version of Herd

Hey, Ludovic Courtès writes: > Hello Alex & Marius, > > Marius Bakke skribis: > >> Alex Sassmannshausen via Bug reports for GNU Guix >> writes: >> >>> Hello, >>> >>> I maintain a number of servers using Guix deploy. It seems that the >>> recent upgrade to Herd in Guix, and specifically commit

bug#41116: Guix deploy fails with new version of Herd

Hello Alex & Marius, Marius Bakke skribis: > Alex Sassmannshausen via Bug reports for GNU Guix > writes: > >> Hello, >> >> I maintain a number of servers using Guix deploy. It seems that the >> recent upgrade to Herd in Guix, and specifically commit >> 4c0cc7bed3de2c0e2d3a6e95b88693941e839eec

bug#41123: shepherd exits for no good reason

Hello, I witnessed a case with Shepherd 0.8.0 on ‘core-updates’ (7b07852ddb334c92bcef69666f21c599f1f0fa79) where shepherd exited all by itself, all of a sudden. Here’s what /var/log/messages shows: --8<---cut here---start->8--- May 7 09:36:23 localhost vmunix

bug#41028: Channel/inferior error with core-updates: Unbound variable: call-with-new-thread

Hi Ludo, On Thu, 7 May 2020 at 10:13, Ludovic Courtès wrote: > Given the enthusiasm expressed on IRC, I went ahead and pushed. :-) > > ff3ca7979e channels: Add patch for . > 053b10c3ef channels: Add mechanism to patch checkouts of the 'guix channel. > 4ba425060

bug#41120: uvesafb service is unsupported on aarch64

On Thu, May 07, 2020 at 09:06:21AM +0200, Mathieu Othacehe wrote: > > Hello Efraim, > > > the uvesafb-service which was added to the installation image isn't > > supported on aarch64 (or probably any non-x86 system) and causes the > > creation of an installation image to fail. > > Thanks for rep

bug#41028: Channel/inferior error with core-updates: Unbound variable: call-with-new-thread

Hey! Ludovic Courtès skribis: > The attached patches add a mechanism to patch the Guix source tree, and > then use that mechanism to add the missing (ice-9 threads) import. With > this I can do: > > ./pre-inst-env guix time-machine \ > --commit=e02c2f85b36ce1c733bd908a210ce1182bdd2560 --

bug#41120: uvesafb service is unsupported on aarch64

On Thu, May 07, 2020 at 09:06:21AM +0200, Mathieu Othacehe wrote: > > Hello Efraim, > > > the uvesafb-service which was added to the installation image isn't > > supported on aarch64 (or probably any non-x86 system) and causes the > > creation of an installation image to fail. > > Thanks for rep

bug#41120: uvesafb service is unsupported on aarch64

Hello Efraim, > the uvesafb-service which was added to the installation image isn't > supported on aarch64 (or probably any non-x86 system) and causes the > creation of an installation image to fail. Thanks for reporting. There's this small snippet in uvesafb-service: --8<---cut he

bug#41121: (Keyboard-layout) form does not work "across the board"

Hej guys, so I hope this actually is a bug and not something not yet implemented or a misunderstanding on my part. In the process of changing my login manager to slim (over gdm), I noticed that the (keyboard-layout ...) form does not work the same way in the (bootloader)/(set-xorg-configurat