[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#56382] bug#20255: [bug#56382] [PATCH] gnu: gajim: Use hicolor-icon-
From: |
bokr |
Subject: |
[bug#56382] 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 |
User-agent: |
Mutt/1.10.1 (2018-07-13) |
Hi Ludo,
On +2022-07-18 11:29:55 +0200, Ludovic Courtès wrote:
> Hi,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
> > Hi Ludovic,
> >
> > Ludovic Courtès <ludo@gnu.org> writes:
> >
> >> Hi,
> >>
> >> "Raghav Gururajan" <rg@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