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

[Marius Bakke]

Leo Famulari  writes:

> 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 it can't find it.

> It's similar with Hexchat; it no longer sees most of the fonts installed
> by Debian.

Just to be clear, these programs are able to find fonts you have
installed through Guix, right?

> The specific fonts in question are the URW fonts, aka the "PostScript
> fonts", provided by Debian's gsfonts and gsfonts-x11 packages.

Are those the only affected fonts?

> $ fc-cache -rv

[...]

> /home/leo/.local/share/fonts: caching, new cache contents: 0 fonts, 0 dirs
> /home/leo/.local/share/fonts: failed to write cache

[...]

> /home/leo/.fonts: caching, new cache contents: 0 fonts, 0 dirs
> /home/leo/.fonts: failed to write cache

[...]

> fc-cache: failed

FWIW the new fc-cache fails for me on Guix System too if I create these
empty directories.

Can you inspect 'fc-list ' with the new and old fontconfig?  Are there
differences?


signature.asc
Description: PGP signature

bug#41120: uvesafb service is unsupported on aarch64

[Mathieu Othacehe]

Hello,

Thanks for working on that Florian & Efraim.

> +   (if (and (string-suffix? "linux-gnu" %host-type)
> +(or (string-prefix? "x86_64" %host-type)
> +(string-prefix? "i686" %host-type)))
> +   #~(lambda ()
> +   ;; uvesafb is only supported on x86 and x86_64.
> +   (or (file-exists? "/dev/fb0")
> +   (invoke #+(file-append kmod "/bin/modprobe")
> +   "uvesafb"
> +   (string-append "v86d=" #$v86d "/sbin/v86d")
> +   "mode_option=1024x768")))
> +   #~(lambda () #t)))
>   (respawn? #f)
>   (one-shot? #t

The issue with using %host-type at build time is that it won't support
system build with --system and --target. For instance if cross-compiling
for aarch64-linux-gnu on a x86_64 system, %host-type will be
"x86_64-..." and we will try to build v86d for aarch64.

We could maybe do something like that:

--8<---cut here---start->8---
(define (operating-system-hardware-specific-services)
  #~(let-system (system target)
(cond
 ((target-arm? system target)
  '())
 ((target-intel? system target)
  (list uvesafb-shepherd-service)

(define (operating-system-kernel-specific-services)
  #~(let-system (system target)
(cond
 ((target-linux? system target)
  linux-specific-services)
 ((target-hurd? system target)
  hurd-specific-services
--8<---cut here---end--->8---

This way, uvesafb-shepherd-service would be built and installed only
when producing a system targeting an Intel CPU. We could also extend
this mechanism to have kernel specific services.

That would mean, we need to dig out Ludo patch introducing
let-system[1], but I think it was almost ready.

Adding janneke, Danny and Ludo to the discussion.

WDYT?

Thanks,

Mathieu

[1]: https://lists.gnu.org/archive/html/guix-patches/2017-11/msg00274.html

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

[Christopher Baines]

Ludovic Courtès  writes:

> 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 -- build linux-libre
>>
>> … which is a simple way to do what the manifest above was about.
>
> 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.
>   4ba425060a channels: Add 'latest-channel-instance'.
>
> So… it might be that today is merge day?

Wonderful :) I've had a chance to try this out now, and it works. I was
able to reconfigure my system.

One even more niche issue is that because I'm using this channel in my
system configuration, the patching happens as root, but it's the cached
channel in my users home directory that's patched. This means that
build-self.scm becomes owned by root.

I noticed this when I went to pull:

  → guix pull --branch=core-updates
  Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
  guix pull: error: Git error: could not open 
'/home/chris/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq/build-aux/build-self.scm'
 for writing: Permission denied


I'm not sure what the neat way of addressing this is, but maybe the file
ownership can be recorded prior to patching, and reset afterwards if
it's changed.

Thanks again for looking at the original issue Ludo,

Chris


signature.asc
Description: PGP signature

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

[Marius Bakke]

Diego Nicola Barbato  writes:

> 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
 4c0cc7bed3de2c0e2d3a6e95b88693941e839eec might have introduced a bug.

 From my testing, guix deploy currently consistently fails with:
 -8<->8---
 ice-9/boot-9.scm:1667:16: In procedure raise-exception:
 ERROR:
   1. &inferior-exception:
   arguments: (srfi-34 #>>> &action-exception-error [service: root action: eval key: 
 keyword-argument-error args: ("#>>> shepherd/service.scm:903:4 (command #:key user group directory 
 environment-variables pid-file pid-file-timeout log-file) | (program . 
 program-args)>" "Unrecognized keyword" () (#:file-creation-mask))] 
 7eff2bd7be00>>)
   inferior: #f
   stack: ()
 -8<->8---

 A workaround is to build the system configuration locally on the target
 server, then to reconfigure.  It will still error at the same place, but
 at this point, after restarting the server, the new version of Herd will
 be running and both deploy and reconfigure will work.

 I don't know what a good solution to this could be, but it may be
 something we need to consider in future development of Herd.
>>>
>>> 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 4c0cc7bed3de2c0e2d3a6e95b88693941e839eec until we find a
>>> smooth upgrade path.  Can you try it and push if that fixes guix deploy?
>>
>> I’ve reverted the patch in 5aa4d2dcf2f4f8786358feb45338893ed08a4cd9.
>>
>> Diego: I guess we can reinstate the patch “later”, once Shepherd 0.8 can
>> be considered widespread.
>
> I'm sorry I broke reconfigure and deploy.  I didn't consider testing
> upgrading from before Shepherd 0.8 to after my change and I didn't even
> think of deploy.  Going forth I'll leave messing with core functionality
> to the pros.

Mistakes happen, don't worry about it.

One thing that would be really useful and can prevent such situations in
the future is to have a "system test" that tries to run reconfigure from
the latest released version of Guix (currently 1.1.0).

There are already a few Shepherd tests in gnu/tests/base.scm and
gnu/tests/reconfigure.scm that can be used as inspiration.

Food for thought, patches welcome, etc.  :-)


signature.asc
Description: PGP signature

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

[Marius Bakke]

Pierre Neidhardt  writes:

> Done in 
> e5f1f5ce07f0976241ed1a68b952b40876eeafba

Thanks for the quick fix!


signature.asc
Description: PGP signature

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

[Marius Bakke]

Christopher Baines  writes:

> Ludovic Courtès  writes:
>
>> 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 -- build linux-libre
>>>
>>> … which is a simple way to do what the manifest above was about.
>>
>> 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.
>>   4ba425060a channels: Add 'latest-channel-instance'.
>>
>> So… it might be that today is merge day?
>
> Wonderful :) I've had a chance to try this out now, and it works. I was
> able to reconfigure my system.
>
> One even more niche issue is that because I'm using this channel in my
> system configuration, the patching happens as root, but it's the cached
> channel in my users home directory that's patched. This means that
> build-self.scm becomes owned by root.
>
> I noticed this when I went to pull:
>
>   → guix pull --branch=core-updates
>   Updating channel 'guix' from Git repository at 
> 'https://git.savannah.gnu.org/git/guix.git'...
>   guix pull: error: Git error: could not open 
> '/home/chris/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq/build-aux/build-self.scm'
>  for writing: Permission denied
>
>
> I'm not sure what the neat way of addressing this is, but maybe the file
> ownership can be recorded prior to patching, and reset afterwards if
> it's changed.

I took a stab at exactly this:

From 993dd0d36ba8e67af5c60d73cb1f9d60741f5418 Mon Sep 17 00:00:00 2001
From: Marius Bakke 
Date: Fri, 8 May 2020 16:23:55 +0200
Subject: [PATCH] channels: Preserve permissions when patching
 .

* guix/channels.scm (%bug-41028-patch): Record permissions before invoking
SUBSTITUTE* and reset afterwards if file permissions differ from the current user.
---
 guix/channels.scm | 19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/guix/channels.scm b/guix/channels.scm
index 0fa036446c..a102d5bc35 100644
--- a/guix/channels.scm
+++ b/guix/channels.scm
@@ -393,10 +393,21 @@ to '%package-module-path'."
(not (string-contains content "(ice-9 threads)"
 
 (define (add-missing-ice-9-threads-import source)
-  ;; Add (ice-9 threads) import in the gexp of 'compute-guix-derivation'.
-  (substitute* (string-append source "/" %self-build-file)
-(("^ +\\(use-modules \\(ice-9 match\\)\\)")
- (object->string '(use-modules (ice-9 match) (ice-9 threads))
+  (let* ((self-build-file (string-append source "/" %self-build-file))
+ ;; Record permissions so that we can reset it afterwards in case
+ ;; we run this as the root user (see ).
+ ;; TODO: Ideally SUBSTITUTE* would preserve permissions itself.
+ (stat  (stat self-build-file))
+ (owner (stat:uid stat))
+ (group (stat:gid stat)))
+
+;; Add (ice-9 threads) import in the gexp of 'compute-guix-derivation'.
+(substitute* self-build-file
+  (("^ +\\(use-modules \\(ice-9 match\\)\\)")
+   (object->string '(use-modules (ice-9 match) (ice-9 threads)
+
+(unless (and (eq? (getuid) owner) (eq? (getgid) group))
+  (chown self-build-file owner group
 
(patch missing-ice-9-threads-import? add-missing-ice-9-threads-import)))
 
-- 
2.26.2


WDYT?

Currently in the process of testing it locally, feedback appreciated.


signature.asc
Description: PGP signature

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

[Christopher Baines]

Marius Bakke  writes:

> Christopher Baines  writes:
>
>> Ludovic Courtès  writes:
>>
>>> 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 -- build linux-libre

 … which is a simple way to do what the manifest above was about.
>>>
>>> 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.
>>>   4ba425060a channels: Add 'latest-channel-instance'.
>>>
>>> So… it might be that today is merge day?
>>
>> Wonderful :) I've had a chance to try this out now, and it works. I was
>> able to reconfigure my system.
>>
>> One even more niche issue is that because I'm using this channel in my
>> system configuration, the patching happens as root, but it's the cached
>> channel in my users home directory that's patched. This means that
>> build-self.scm becomes owned by root.
>>
>> I noticed this when I went to pull:
>>
>>   → guix pull --branch=core-updates
>>   Updating channel 'guix' from Git repository at 
>> 'https://git.savannah.gnu.org/git/guix.git'...
>>   guix pull: error: Git error: could not open 
>> '/home/chris/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq/build-aux/build-self.scm'
>>  for writing: Permission denied
>>
>>
>> I'm not sure what the neat way of addressing this is, but maybe the file
>> ownership can be recorded prior to patching, and reset afterwards if
>> it's changed.
>
> I took a stab at exactly this:

Awesome, thanks. I haven't tried it, but it looks good :)


signature.asc
Description: PGP signature

bug#41138: [ICEDOVE]: Preferences does not open.

[Raghav Gururajan]

Hello Guix!

First of, many thanks to Jonathan Brielmaier, Nikita, Adrian Malacoda and
Ricardo Wurmus; for making Icedove in Guix happen. :-)

When I tried it, I got the following error on opening "Preferences".

XML Parsing Error: undefined entity
Location: about:preferences
Line Number 780, Column 17:

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

[Leo Famulari]

On Fri, May 08, 2020 at 10:59:46AM +0200, Marius Bakke wrote:
> Just to be clear, these programs are able to find fonts you have
> installed through Guix, right?

They can find the font packages I install with Guix, but not the
hard-coded PostScript fonts.

> > The specific fonts in question are the URW fonts, aka the "PostScript
> > fonts", provided by Debian's gsfonts and gsfonts-x11 packages.
> 
> Are those the only affected fonts?

I looked more closely, and Guix applications can no longer see *any*
fonts from Debian.

> > $ fc-cache -rv
> 
> [...]
> 
> > /home/leo/.local/share/fonts: caching, new cache contents: 0 fonts, 0 dirs
> > /home/leo/.local/share/fonts: failed to write cache
> 
> [...]
> 
> > /home/leo/.fonts: caching, new cache contents: 0 fonts, 0 dirs
> > /home/leo/.fonts: failed to write cache
> 
> [...]
> 
> > fc-cache: failed
> 
> FWIW the new fc-cache fails for me on Guix System too if I create these
> empty directories.

Confirmed. fc-cache exited successfully when I removed those directories.

> Can you inspect 'fc-list ' with the new and old fontconfig?  Are there
> differences?

The only differences, after running `fc-cache -rfv`, are the differing
store paths of the hard-coded gs-fonts package.

Another thing I noticed is that I can do `fc-cache -rfv /usr/share/fonts
&& fc-list`, and the hundreds of fonts found in that directory are *not
shown* in fc-list, but that's the same as on the master branch.

So, I'm still not sure what the difference is.


signature.asc
Description: PGP signature

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

[Marius Bakke]

Marius Bakke  writes:

> Christopher Baines  writes:
>
>> One even more niche issue is that because I'm using this channel in my
>> system configuration, the patching happens as root, but it's the cached
>> channel in my users home directory that's patched. This means that
>> build-self.scm becomes owned by root.
>>
>> I noticed this when I went to pull:
>>
>>   → guix pull --branch=core-updates
>>   Updating channel 'guix' from Git repository at 
>> 'https://git.savannah.gnu.org/git/guix.git'...
>>   guix pull: error: Git error: could not open 
>> '/home/chris/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq/build-aux/build-self.scm'
>>  for writing: Permission denied
>>
>>
>> I'm not sure what the neat way of addressing this is, but maybe the file
>> ownership can be recorded prior to patching, and reset afterwards if
>> it's changed.
>
> I took a stab at exactly this:
>
> From 993dd0d36ba8e67af5c60d73cb1f9d60741f5418 Mon Sep 17 00:00:00 2001
> From: Marius Bakke 
> Date: Fri, 8 May 2020 16:23:55 +0200
> Subject: [PATCH] channels: Preserve permissions when patching
>  .
>
> * guix/channels.scm (%bug-41028-patch): Record permissions before invoking
> SUBSTITUTE* and reset afterwards if file permissions differ from the current 
> user.
> ---
>  guix/channels.scm | 19 +++
>  1 file changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/guix/channels.scm b/guix/channels.scm
> index 0fa036446c..a102d5bc35 100644
> --- a/guix/channels.scm
> +++ b/guix/channels.scm
> @@ -393,10 +393,21 @@ to '%package-module-path'."
> (not (string-contains content "(ice-9 threads)"
>  
>  (define (add-missing-ice-9-threads-import source)
> -  ;; Add (ice-9 threads) import in the gexp of 'compute-guix-derivation'.
> -  (substitute* (string-append source "/" %self-build-file)
> -(("^ +\\(use-modules \\(ice-9 match\\)\\)")
> - (object->string '(use-modules (ice-9 match) (ice-9 threads))
> +  (let* ((self-build-file (string-append source "/" %self-build-file))
> + ;; Record permissions so that we can reset it afterwards in case
> + ;; we run this as the root user (see 
> ).
> + ;; TODO: Ideally SUBSTITUTE* would preserve permissions itself.
> + (stat  (stat self-build-file))
> + (owner (stat:uid stat))
> + (group (stat:gid stat)))
> +
> +;; Add (ice-9 threads) import in the gexp of 
> 'compute-guix-derivation'.
> +(substitute* self-build-file
> +  (("^ +\\(use-modules \\(ice-9 match\\)\\)")
> +   (object->string '(use-modules (ice-9 match) (ice-9 threads)
> +
> +(unless (and (eq? (getuid) owner) (eq? (getgid) group))
> +  (chown self-build-file owner group
>  
> (patch missing-ice-9-threads-import? add-missing-ice-9-threads-import)))

Ludovic pointed out on IRC that 'sudo guix system build foo.scm' with an
inferior will update the cached checkout (typically
~/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq)
as root, and break subsequent unprivileged 'guix pull' operations anyway.

Which is partially correct: .git/index and .git/refs/heads/master will
be owned by root in that case, but you are still allowed to unlink() and
rename() such files as long as you own the directory, so libgit2 will
successfully reset permissions on the checkout even after pulling as
root!

It fails to do that for build-self.scm because it does not know it has
changed, and tries opening it directly with O_WRONLY (which fails).  I
can confirm that this patch solves that problem, and unprivileged 'guix
pull' works again even after previously using sudo.

Now, users are likely to run into other issues when using inferiors with
sudo (e.g. if new directories are added), so I'm not sure if this patch
is worth the effort.

Perhaps the Guix git cache should be per-uid, but that requires more
intrusive changes.

Thoughts?


signature.asc
Description: PGP signature

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

[Leo Famulari]

On Thu, May 07, 2020 at 10:25:44PM -0400, Leo Famulari wrote:
> 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 serious problems
> on those distros, yet it hasn't been released by fontconfig yet.

This didn't have any effect.

bug#41138: [ICEDOVE]: Hogs-up system resources upon connection.

[Raghav Gururajan]

Hello Guix!

First of, many thanks to Jonathan Brielmaier, Nikita, Adrian Malacoda and
Ricardo Wurmus; for making Icedove in Guix happen. :-)

To try out the application, I connected to chat.freenode.net and joined
#freenode. As soon as I connect and join, the whole-system started to become
laggy. When I typed something in icedove, they appeared with delay. Also, when I
checked with 'top' command, icedove's CPU was hitting %101.7.

Regards,
RG.

bug#41139: duplicate service provision error message is too terse

[Ricardo Wurmus]

“guix system” prints a very terse error message when a display manager
is added on top of %desktop-services:

guix system: error: service 'xorg-server' provided more than once

This is not very helpful, because it’s hard to tell how we got there.
Which of the selected services provide xorg-server?

It would be nice if the error message could be a little more helpful.

-- 
Ricardo

bug#41140: “guix system” suggests wrong module import when using “remove”

[Ricardo Wurmus]

I want to delete a service from %desktop-services, so I write

--8<---cut here---start->8---
…
(services (remove
   (lambda (service)
 (eq? (service-kind service) that-annoying-service-type))
   %desktop-services))
…
--8<---cut here---end--->8---

Then I run “guix system build config.scm” and Guix tells me that it
doesn’t know what “remove” is:

--8<---cut here---start->8---
config.scm:56:18: error: remove: unbound variable
hint: Did you forget `(use-modules (rnrs lists))'?
--8<---cut here---end--->8---

I add the suggested module import to my file and it no longer complains,
but that-annoying-service-type has not actually been removed.  Oh no!

Of course, the Guix manual says this:

--8<---cut here---start->8---
   Again, ‘%desktop-services’ is just a list of service objects.  If you
want to remove services from there, you can do so using the procedures
for list filtering (*note (guile)SRFI-1 Filtering and Partitioning::).
For instance, the following expression returns a list that contains all
the services in ‘%desktop-services’ minus the Avahi service:

 (remove (lambda (service)
   (eq? (service-kind service) avahi-service-type))
 %desktop-services)
--8<---cut here---end--->8---

But maybe I don’t know what SRFI-1 is and I trust that the hint Guix
provides will be the right thing to do.

But now I’m curious and I look at the documentation for “remove” from
(rnrs lists):

--8<---cut here---start->8---
 -- Scheme Procedure: remp proc list
 -- Scheme Procedure: remove obj list
 -- Scheme Procedure: remv obj list
 -- Scheme Procedure: remq obj list
 ‘remove’, ‘remv’, and ‘remq’ are identical to the ‘delete’, ‘delv’,
 and ‘delq’ procedures provided by Guile’s core library, (*note List
 Modification::).  ‘remp’ is identical to the alternate ‘remove’
 procedure provided by SRFI-1; *Note SRFI-1 Deleting::.
--8<---cut here---end--->8---

Oh.

So here are my questions:

* can we prefer (srfi srfi-1) over (rnrs lists) in the suggestions for “remove”?

* can we avoid this by extending modify-services to support “delete”
  much like modify-phases, and suggesting to use that instead of
  “remove”?

--
Ricardo

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

[Bengt Richter]

Hi Leo, et al,

On +2020-05-08 14:08:51 -0400, Leo Famulari wrote:
> On Fri, May 08, 2020 at 10:59:46AM +0200, Marius Bakke wrote:
> > Just to be clear, these programs are able to find fonts you have
> > installed through Guix, right?
> 
> They can find the font packages I install with Guix, but not the
> hard-coded PostScript fonts.
> 
> > > The specific fonts in question are the URW fonts, aka the "PostScript
> > > fonts", provided by Debian's gsfonts and gsfonts-x11 packages.
> > 
> > Are those the only affected fonts?
> 
> I looked more closely, and Guix applications can no longer see *any*
> fonts from Debian.
> 
> > > $ fc-cache -rv
> > 
> > [...]
> > 
> > > /home/leo/.local/share/fonts: caching, new cache contents: 0 fonts, 0 dirs
> > > /home/leo/.local/share/fonts: failed to write cache
> > 
> > [...]
> > 
> > > /home/leo/.fonts: caching, new cache contents: 0 fonts, 0 dirs
> > > /home/leo/.fonts: failed to write cache
> > 
> > [...]
> > 
> > > fc-cache: failed
> > 
> > FWIW the new fc-cache fails for me on Guix System too if I create these
> > empty directories.
> 
> Confirmed. fc-cache exited successfully when I removed those directories.
> 
> > Can you inspect 'fc-list ' with the new and old fontconfig?  Are there
> > differences?
> 
> The only differences, after running `fc-cache -rfv`, are the differing
> store paths of the hard-coded gs-fonts package.
> 
> Another thing I noticed is that I can do `fc-cache -rfv /usr/share/fonts
> && fc-list`, and the hundreds of fonts found in that directory are *not
> shown* in fc-list, but that's the same as on the master branch.
> 
> So, I'm still not sure what the difference is.

Didn't I just see a permissions-related bug reminiscent of this go by a short 
while ago?
Could it be related? Do the dir/file perms look normal?

-- 
Regards,
Bengt Richter

bug#40832: Audacity does not work with PulseAudio

[Leo Famulari]

An update on this:

To begin, I installed alsa-plugins and alsa-plugins:pulseaudio and
configured the build of alsa-lib like this:

"--with-plugindir=/var/guix/profiles/per-user/leo/guix-profile/lib/alsa-lib"

Everything worked that way, but obviously it's not a solution.

Now, I am working on making alsa-lib respect ALSA_PLUGIN_DIRS, which
would be a search path specified by packages that provide ALSA plugins,
such as alsa-plugins. However, so far my attempt fails in another part
of alsa-lib, like this:

--
$ mpg123 -o alsa ~/file.mp3
ALSA lib dlmisc.c:204:(snd_dlsym_verify) unable to verify version for symbol 
conf_pulse_hook_load_if_running
ALSA lib conf.c:3686:(snd_config_hooks_call) symbol 
conf_pulse_hook_load_if_running is not defined inside 
libasound_module_conf_pulse.so
ALSA lib pcm.c:2685:(snd_pcm_open_noupdate) Unknown PCM default
[src/libout123/modules/alsa.c:181] error: cannot open device default
[src/libout123/libout123.c:455] error: Found no driver out of [alsa] working 
with device .
main: [src/mpg123.c:314] error: out123 error 3: failure loading driver module
--

I don't know why snd_dlsym_verify fails with my patch but succeeds when
using '--with-plugindir'.

My current patch is attached...
From 2dc0cf223a71d2a22ca19eff6c59d55d72028c64 Mon Sep 17 00:00:00 2001
From: Leo Famulari 
Date: Sun, 26 Apr 2020 20:13:01 -0400
Subject: [PATCH 1/3] gnu: alsa-plugins: Add ALSA_PLUGIN_DIRS search path
 specification.

* gnu/packages/linux.scm (alsa-plugins)[native-search-paths]: New field.
---
 gnu/packages/linux.scm | 4 
 1 file changed, 4 insertions(+)

diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index 40323a85d6..b451f591ea 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -1858,6 +1858,10 @@ MIDI functionality to the Linux-based operating system.")
   (base32
"0z9k3ssbfk2ky2w13avgyf202j1drsz9sv3834bp33cj1i2hc3qw"
 (build-system gnu-build-system)
+(native-search-paths
+  (list (search-path-specification
+  (variable "ALSA_PLUGIN_DIRS")
+  (files '("lib/alsa-lib")
 ;; TODO: Split libavcodec and speex if possible. It looks like they can not
 ;; be split, there are references to both in files.
 ;; TODO: Remove OSS related plugins, they add support to run native
-- 
2.26.2


From a9ce47575add9eeb015eb6c605bde01948c5e341 Mon Sep 17 00:00:00 2001
From: Leo Famulari 
Date: Mon, 27 Apr 2020 01:05:41 -0400
Subject: [PATCH 2/3] gnu: Add the old Nix alsa-lib patch with a graft.

* gnu/packages/linux.scm (alsa-lib)[replacement]: New field.
(alsa-lib/fixed): New variable.
* gnu/packages/patches/alsa-lib.patch: New file.
* gnu/local.mk (dist_patch_DATA): Add it.
---
 gnu/local.mk|   1 +
 gnu/packages/linux.scm  |  10 +++
 gnu/packages/patches/alsa-lib.patch | 110 
 3 files changed, 121 insertions(+)
 create mode 100644 gnu/packages/patches/alsa-lib.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index 39267f2765..de17670beb 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -741,6 +741,7 @@ dist_patch_DATA =   
\
   %D%/packages/patches/akonadi-not-relocatable.patch   \
   %D%/packages/patches/akonadi-timestamps.patch\
   %D%/packages/patches/allegro-mesa-18.2.5-and-later.patch \
+  %D%/packages/patches/alsa-lib.patch  \
   %D%/packages/patches/amule-crypto-6.patch\
   %D%/packages/patches/anki-mpv-args.patch \
   %D%/packages/patches/antiword-CVE-2014-8123.patch\
diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index b451f591ea..e0ed8c040d 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -1771,6 +1771,7 @@ intercept and print the system calls executed by the 
program.")
 (define-public alsa-lib
   (package
 (name "alsa-lib")
+(replacement alsa-lib/fixed)
 (version "1.2.2")
 (source (origin
  (method url-fetch)
@@ -1792,6 +1793,15 @@ intercept and print the system calls executed by the 
program.")
 MIDI functionality to the Linux-based operating system.")
 (license license:lgpl2.1+)))
 
+(define alsa-lib/fixed
+  (package
+(inherit alsa-lib)
+(source (origin
+  (inherit (package-source alsa-lib))
+  (patches (append
+ (origin-patches (package-source alsa-lib))
+ (search-patches "alsa-lib.patch")))
+
 (define-public alsa-utils
   (package
 (name "alsa-utils")
diff --git a/gnu/packages/patches/alsa-lib.patch 
b/gnu/packages/patches/alsa-lib.patch
new file mode 100644
index 00..3cee02aa0c
--- /dev/null
+++ b/gnu/packages/patches/alsa-lib.patch
@@ -0,0 +1,110 @@
+diff --git a/src/pcm/pcm.c b/src/pcm/pcm.c
+index 74d1d1a..17ffb12 100644
+--- a/src/pcm/pcm.c
 b/src/pcm/pcm.c
+@@ -2042,6 +2042,19 @@ static const char *co

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

[Leo Famulari]

On Sat, May 09, 2020 at 12:18:46AM +0200, Bengt Richter wrote:
> Didn't I just see a permissions-related bug reminiscent of this go by a short 
> while ago?
> Could it be related? Do the dir/file perms look normal?

Upthread, Tobias pointed out that fc-cache didn't have permissions for
/var/cache/fontconfig, but deleting that didn't seem to make a
difference. Could that be what you were thinking about?

bug#40832: Audacity does not work with PulseAudio

[Leo Famulari]

On Fri, May 08, 2020 at 06:45:18PM -0400, Leo Famulari wrote:
> My current patch is attached...

I already found a lot of problems with patch 3/3... Don't look too
closely at it :)


signature.asc
Description: PGP signature

bug#41025: blueman does not start

[Raghav Gururajan]

Hi Pierre!

Please find the new patch attached with this email. It fixes the
discussed issues. Now, blueman just needs "dbus-launch", which I think
provided by %desktop-services.

If you could push this patch, that would be great.

Thank you!

Regards,
RG.
From be674bd528cbcb16e04368e1f01beaffac912a61 Mon Sep 17 00:00:00 2001
From: Raghav Gururajan 
Date: Sat, 9 May 2020 02:17:21 -0400
Subject: [PATCH] gnu: blueman: Update package definition.

* gnu/packages/networking.scm (blueman): Fixes.
[version]: Upgrade to 2.1.3.
[source][method]: Change from url-fetch to git-fetch.
[arguments]<#:phases>['setenv]: New phase.
['patch-python-references]: New phase.
['wrap-blueman-progs]: New phase.
[native-inputs]: Add autoconf, autogen and automake.
[inputs]: Add gobject-introspection. Replace libnma with network-manager.
---
 gnu/packages/networking.scm | 65 ++---
 1 file changed, 54 insertions(+), 11 deletions(-)

diff --git a/gnu/packages/networking.scm b/gnu/packages/networking.scm
index d7720724cc..bbdf42c1f7 100644
--- a/gnu/packages/networking.scm
+++ b/gnu/packages/networking.scm
@@ -72,6 +72,7 @@
   #:use-module (gnu packages adns)
   #:use-module (gnu packages algebra)
   #:use-module (gnu packages audio)
+  #:use-module (gnu packages autogen)
   #:use-module (gnu packages autotools)
   #:use-module (gnu packages base)
   #:use-module (gnu packages bison)
@@ -127,36 +128,78 @@
 (define-public blueman
   (package
 (name "blueman")
-(version "2.1.2")
+(version "2.1.3")
 (source
  (origin
-   (method url-fetch)
+   (method git-fetch)
(uri
-(string-append "https://github.com/blueman-project/blueman/releases/";
-   "download/2.1.2/blueman-2.1.2.tar.gz"))
+(git-reference
+ (url "https://github.com/blueman-project/blueman.git";)
+ (commit version)))
+   (file-name (git-file-name name version))
(sha256
-(base32 "0wamxdw36c8i3aqwmja5q70fajqwd7inpkvlpkldd54wdxbcd38d"
+(base32 "1vb0zfns4q5d65hnja4c0k11lr38xxhdnkpkzfs6xca3mm6jyi1d"
 (build-system glib-or-gtk-build-system)
 (arguments
  `(#:configure-flags
(list
 "--enable-polkit"
 "--disable-appindicator" ; Deprecated
-"--with-systemdsystemunitdir=no" ; Not required
-"--with-systemduserunitdir=no")))  ; Not required
+"--without-systemdsystemunitdir" ; Not required
+"--without-systemduserunitdir")  ; Not required
+   #:phases
+   (modify-phases %standard-phases
+ (add-before 'bootstrap 'setenv
+   ;; Prevent the autogen.sh script to carry out the configure
+   ;; script, which has not yet been patched to replace /bin/sh.
+   (lambda _
+ (setenv "NOCONFIGURE" "TRUE")
+ #t))
+ ;; Python references are not being patched in patch-phase of build;
+ ;; despite using python-wrapper as input. So patching them manually.
+ (add-after 'unpack 'patch-python-references
+   (lambda* (#:key inputs #:allow-other-keys)
+ (with-directory-excursion "apps"
+   (substitute* '("blueman-adapters.in" "blueman-applet.in"
+  "blueman-assistant.in" "blueman-manager.in"
+  "blueman-mechanism.in" "blueman-report.in"
+  "blueman-rfcomm-watcher.in" "blueman-sendto.in"
+  "blueman-services.in" "blueman-tray.in")
+ (("@PYTHON@") (string-append (assoc-ref inputs "python")
+  "/bin/python3.7"
+ #t))
+ (add-after 'glib-or-gtk-wrap 'wrap-blueman-progs
+   (lambda* (#:key outputs #:allow-other-keys)
+ (let* ((out (assoc-ref outputs "out"))
+(bin (string-append out "/bin/blueman-"))
+(lib (string-append out "/lib/python3.7/site-packages/")))
+   (for-each
+(lambda (program)
+  (pk program)
+  (pk (string-append bin program))
+  (wrap-program (string-append bin program)
+`("PYTHONPATH" = (,(getenv "PYTHONPATH")
+  ,lib))
+`("GI_TYPELIB_PATH" = (,(getenv "GI_TYPELIB_PATH")
+'("adapters" "applet" "assistant" "manager" "report"
+  "sendto" "services" "tray"))
+   #t))
 (native-inputs
- `(("cython" ,python-cython)
+ `(("autoconf" ,autoconf)
+   ("autogen" ,autogen)
+   ("automake" ,automake)
+   ("cython" ,python-cython)
("glib:bin" ,glib "bin")
("gtk+:bin" ,gtk+ "bin")
("intltool" ,intltool)
("libtool" ,libtool)
("pkg-config" ,pkg-config)))
 (inputs
- `(("adwaita-icon-theme" ,adwaita-icon-theme)
-   ("bluez" ,bluez)
+ `(("bluez" ,bluez)
 

bug#41138: [ICEDOVE]: Preferences does not open.

[Raghav Gururajan]

Hello Guix!

So I tried opening icedove from terminal, to see more information about
the error. It appears the error has its origin from a file called
"Overlays.jsm".

Regards,
RG.


0xAE6EF3046D6F7B57.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature