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 >

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.

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

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

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

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

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

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

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

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

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

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

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

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

bug#39527: A new information on LXQt DE not "logging in"

Hello guys, I have come to realise something which might be of interest, but which might also be something which is well known to you. When trying to launch LXQt from the GDM login/session manager, the screen just went blank and nothing happened. This is why I assumed "it simply doesnt