GNU bug report logs - #20255
'search-paths' should respect both user and system profile.

Previous Next

Full log

Message #121 received at 20255 <at> debbugs.gnu.org (full text, mbox):

From: bokr <at> bokr.com
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Raghav Gururajan <rg <at> raghavgururajan.name>, Morgan.J.Smith <at> outlook.com,
 56382 <at> debbugs.gnu.org, Maxim Cournoyer <maxim.cournoyer <at> gmail.com>,
 20255 <at> debbugs.gnu.org
Subject: Re: bug#20255: [bug#56382] [PATCH] gnu: gajim: Use
 hicolor-icon-theme to avoid crashing on startup
Date: Mon, 18 Jul 2022 15:33:18 +0200

Hi Ludo,

On +2022-07-18 11:29:55 +0200, Ludovic Courtès wrote:
> Hi,
> 
> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:
> 
> > Hi Ludovic,
> >
> > Ludovic Courtès <ludo <at> gnu.org> writes:
> >
> >> Hi,
> >>
> >> "Raghav Gururajan" <rg <at> raghavgururajan.name> skribis:
> >>
> >>>> Does simply adding ‘hicolor-icon-theme’ to ‘inputs’ fix the issue?
> >>>
> >>> Most gtk-based apps expect hicolor-icon-theme and adwaita-icon-theme to be in the profile. Adding these in either system or user profile would prevent this error from occurring.
> >>
> >> Right, so the proposed patch (adding ‘hicolor-icon-theme’ to ‘inputs’,
> >> not ‘propagated-inputs’) shouldn’t make any difference I guess?
> >
> > I think it works as inputs because of our wrappers (perhaps
> > XDG_DATA_DIRS)?  But it's kind at odds with our policy which is to let
> > users manage icons themselves.
> 
> Yeah.
> 
> > Probably because of #20255 that wouldn't help currently (system and user
> > profiles are not merged), but if we fixed that bug we could make the
> > situation better by adding 'hicolor-icon-theme' to the default packages
> > of our desktop system templates.
> 
> Right.
> 
> BTW, the reason the solution at <https://issues.guix.gnu.org/20255#12>
> was rejected could be revisited.  Since that time, search paths made it
> into the manifest itself, which brings a speed up:
> 
> --8<---------------cut here---------------start------------->8---
> $ sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches '
> $ time guix package -p ~/.guix-home/profile -p /run/current-system/profile --search-paths > /dev/null
> 
> real    0m0.540s
> user    0m0.131s
> sys     0m0.063s
> $ time guix package -p ~/.guix-home/profile -p /run/current-system/profile --search-paths > /dev/null
> 
> real    0m0.135s
> user    0m0.130s
> sys     0m0.024s
> --8<---------------cut here---------------end--------------->8---
> 
> Thoughts?
> 
> Ludo’.

I'm sure you were just after a quick indication and know what can affect timing,
but I'm curious:

What would the above results be if you did the second timing
first, after a power down and cold start?

I'm guessing the kernel file systems are pretty clever about
caching stuff, especially if you have lots of ram :)

I.e., what cached state could the first timing have left for the second to profit from?

(I've been fooled maany times, benchmarking and timing :)

--
Regards,
Bengt Richter

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.