bug#20255: [bug#56382] [PATCH] gnu: gajim: Use hicolor-icon-theme to avoid crashing on startup

[Ludovic Courtès]

Hi,

b...@bokr.com skribis:

> 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 :)

The ‘drop_caches’ command is meant to drop all caches, as if I were
doing it on a cold start.

Ludo’.

bug#20255: [bug#56382] [PATCH] gnu: gajim: Use hicolor-icon-theme to avoid crashing on startup

[bokr]

Hi Ludo,

On +2022-07-18 11:29:55 +0200, Ludovic Courtès wrote:
> Hi,
> 
> Maxim Cournoyer  skribis:
> 
> > Hi Ludovic,
> >
> > Ludovic Courtès  writes:
> >
> >> Hi,
> >>
> >> "Raghav Gururajan"  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 
> 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
> 
> real0m0.540s
> user0m0.131s
> sys 0m0.063s
> $ time guix package -p ~/.guix-home/profile -p /run/current-system/profile 
> --search-paths > /dev/null
> 
> real0m0.135s
> user0m0.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

bug#20255: [bug#56382] [PATCH] gnu: gajim: Use hicolor-icon-theme to avoid crashing on startup

[Maxim Cournoyer]

Hello!

Ludovic Courtès  writes:

[...]

>>> 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 
> was rejected could be revisited.  Since that time, search paths made it
> into the manifest itself, which brings a speed up:
>
> $ 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
>
> real0m0.540s
> user0m0.131s
> sys 0m0.063s
> $ time guix package -p ~/.guix-home/profile -p /run/current-system/profile 
> --search-paths > /dev/null
>
> real0m0.135s
> user0m0.130s
> sys 0m0.024s
>
> Thoughts?

Re-reading the bug report, we had come up with a blueprint of a possible
solution  but failed short of implementing it [0]

[0]  https://issues.guix.gnu.org/20255#35

Even the --search-paths command become 0.2 s, I don't think it'll
satisfy all parties, so the solution above still has merit, I think.
Perhaps we should try to implement it, unless you see a problem with it.

Thanks,

Maxim

bug#20255: [bug#56382] [PATCH] gnu: gajim: Use hicolor-icon-theme to avoid crashing on startup

[Ludovic Courtès]

Hi,

Maxim Cournoyer  skribis:

> Hi Ludovic,
>
> Ludovic Courtès  writes:
>
>> Hi,
>>
>> "Raghav Gururajan"  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 
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

real0m0.540s
user0m0.131s
sys 0m0.063s
$ time guix package -p ~/.guix-home/profile -p /run/current-system/profile 
--search-paths > /dev/null

real0m0.135s
user0m0.130s
sys 0m0.024s
--8<---cut here---end--->8---

Thoughts?

Ludo’.