Patchwork [4/5] gtk-icon-cache: call postinst scriplet at do_rootfs time

login
register
mail settings
Submitter Laurentiu Palcu
Date Aug. 3, 2012, 8:19 p.m.
Message ID <b41b2c46c9de5d3f63bfa146e23e8974a7a6cebf.1344022584.git.laurentiu.palcu@intel.com>
Download mbox | patch
Permalink /patch/33763/
State New
Headers show

Comments

Laurentiu Palcu - Aug. 3, 2012, 8:19 p.m.
This will improve first boot time because building the icon cache is
done on host, with more processing power than the target.

Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
---
 meta/classes/gtk-icon-cache.bbclass |   10 ++--------
 1 file changed, 2 insertions(+), 8 deletions(-)
Andreas Müller - Aug. 3, 2012, 11:22 p.m.
On Fri, Aug 3, 2012 at 10:19 PM, Laurentiu Palcu
<laurentiu.palcu@intel.com> wrote:
> This will improve first boot time because building the icon cache is
> done on host, with more processing power than the target.
>
> Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
> ---
>  meta/classes/gtk-icon-cache.bbclass |   10 ++--------
>  1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/meta/classes/gtk-icon-cache.bbclass b/meta/classes/gtk-icon-cache.bbclass
> index 01fb2f3..2d82c54 100644
> --- a/meta/classes/gtk-icon-cache.bbclass
> +++ b/meta/classes/gtk-icon-cache.bbclass
> @@ -1,18 +1,12 @@
>  FILES_${PN} += "${datadir}/icons/hicolor"
>
> -DEPENDS += "${@['hicolor-icon-theme', '']['${BPN}' == 'hicolor-icon-theme']}"
> +DEPENDS += "${@['hicolor-icon-theme', '']['${BPN}' == 'hicolor-icon-theme']} gtk+-native"
>
> -# This could run on the host as icon cache files are architecture independent,
> -# but there is no gtk-update-icon-cache built natively.
>  gtk_icon_cache_postinst() {
> -if [ "x$D" != "x" ]; then
> -        exit 1
> -fi
> -
>  # Update the pixbuf loaders in case they haven't been registered yet
>  GDK_PIXBUF_MODULEDIR=${libdir}/gdk-pixbuf-2.0/2.10.0/loaders gdk-pixbuf-query-loaders --update-cache
>
> -for icondir in /usr/share/icons/* ; do
> +for icondir in $D/usr/share/icons/* ; do
>      if [ -d $icondir ] ; then
>          gtk-update-icon-cache -fqt  $icondir
>      fi
> --
> 1.7.9.5
>
Long time ago there was a patch introducing gtk-icon-cache to be only
run once on the machine [1] and I am still using that. At that time I
was asked for a more generic approach. Now I ask:

1. Wouldn't it be better to have gtk-icon-cache run once even on host
2. Or better: How about a postinst 'runonce' framework for host/machine?

Andreas

[1] http://patches.openembedded.org/patch/24179/
Laurentiu Palcu - Aug. 4, 2012, 7:49 a.m.
On 08/04/2012 02:22 AM, Andreas Müller wrote:
> On Fri, Aug 3, 2012 at 10:19 PM, Laurentiu Palcu
> <laurentiu.palcu@intel.com> wrote:
>> This will improve first boot time because building the icon cache is
>> done on host, with more processing power than the target.
>>
>> Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
>> ---
>>  meta/classes/gtk-icon-cache.bbclass |   10 ++--------
>>  1 file changed, 2 insertions(+), 8 deletions(-)
>>
>> diff --git a/meta/classes/gtk-icon-cache.bbclass b/meta/classes/gtk-icon-cache.bbclass
>> index 01fb2f3..2d82c54 100644
>> --- a/meta/classes/gtk-icon-cache.bbclass
>> +++ b/meta/classes/gtk-icon-cache.bbclass
>> @@ -1,18 +1,12 @@
>>  FILES_${PN} += "${datadir}/icons/hicolor"
>>
>> -DEPENDS += "${@['hicolor-icon-theme', '']['${BPN}' == 'hicolor-icon-theme']}"
>> +DEPENDS += "${@['hicolor-icon-theme', '']['${BPN}' == 'hicolor-icon-theme']} gtk+-native"
>>
>> -# This could run on the host as icon cache files are architecture independent,
>> -# but there is no gtk-update-icon-cache built natively.
>>  gtk_icon_cache_postinst() {
>> -if [ "x$D" != "x" ]; then
>> -        exit 1
>> -fi
>> -
>>  # Update the pixbuf loaders in case they haven't been registered yet
>>  GDK_PIXBUF_MODULEDIR=${libdir}/gdk-pixbuf-2.0/2.10.0/loaders gdk-pixbuf-query-loaders --update-cache
>>
>> -for icondir in /usr/share/icons/* ; do
>> +for icondir in $D/usr/share/icons/* ; do
>>      if [ -d $icondir ] ; then
>>          gtk-update-icon-cache -fqt  $icondir
>>      fi
>> --
>> 1.7.9.5
>>
> Long time ago there was a patch introducing gtk-icon-cache to be only
> run once on the machine [1] and I am still using that. At that time I
> was asked for a more generic approach. Now I ask:
> 
> 1. Wouldn't it be better to have gtk-icon-cache run once even on host
But this is what these patches do. Make gtk-update-icon-cache run on
host, when the target rootfs is constructed, rather than running it on
target, at first boot.

Thanks,
Laurentiu

> 2. Or better: How about a postinst 'runonce' framework for host/machine?
> 
> Andreas
> 
> [1] http://patches.openembedded.org/patch/24179/
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
Andreas Müller - Aug. 4, 2012, 9:29 a.m.
On Sat, Aug 4, 2012 at 9:49 AM, Laurentiu Palcu
<laurentiu.palcu@intel.com> wrote:
>
>
> On 08/04/2012 02:22 AM, Andreas Müller wrote:
>> On Fri, Aug 3, 2012 at 10:19 PM, Laurentiu Palcu
>> <laurentiu.palcu@intel.com> wrote:
>>> This will improve first boot time because building the icon cache is
>>> done on host, with more processing power than the target.
>>>
>>> Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
>>> ---
>>>  meta/classes/gtk-icon-cache.bbclass |   10 ++--------
>>>  1 file changed, 2 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/meta/classes/gtk-icon-cache.bbclass b/meta/classes/gtk-icon-cache.bbclass
>>> index 01fb2f3..2d82c54 100644
>>> --- a/meta/classes/gtk-icon-cache.bbclass
>>> +++ b/meta/classes/gtk-icon-cache.bbclass
>>> @@ -1,18 +1,12 @@
>>>  FILES_${PN} += "${datadir}/icons/hicolor"
>>>
>>> -DEPENDS += "${@['hicolor-icon-theme', '']['${BPN}' == 'hicolor-icon-theme']}"
>>> +DEPENDS += "${@['hicolor-icon-theme', '']['${BPN}' == 'hicolor-icon-theme']} gtk+-native"
>>>
>>> -# This could run on the host as icon cache files are architecture independent,
>>> -# but there is no gtk-update-icon-cache built natively.
>>>  gtk_icon_cache_postinst() {
>>> -if [ "x$D" != "x" ]; then
>>> -        exit 1
>>> -fi
>>> -
>>>  # Update the pixbuf loaders in case they haven't been registered yet
>>>  GDK_PIXBUF_MODULEDIR=${libdir}/gdk-pixbuf-2.0/2.10.0/loaders gdk-pixbuf-query-loaders --update-cache
>>>
>>> -for icondir in /usr/share/icons/* ; do
>>> +for icondir in $D/usr/share/icons/* ; do
>>>      if [ -d $icondir ] ; then
>>>          gtk-update-icon-cache -fqt  $icondir
>>>      fi
>>> --
>>> 1.7.9.5
>>>
>> Long time ago there was a patch introducing gtk-icon-cache to be only
>> run once on the machine [1] and I am still using that. At that time I
>> was asked for a more generic approach. Now I ask:
>>
>> 1. Wouldn't it be better to have gtk-icon-cache run once even on host
> But this is what these patches do. Make gtk-update-icon-cache run on
> host, when the target rootfs is constructed, rather than running it on
> target, at first boot.
As far as I can see gtk-icon-cache is run for each package - how much
extra build time at do_rootfs is to expect?

Andreas
>
> Thanks,
> Laurentiu
>
>> 2. Or better: How about a postinst 'runonce' framework for host/machine?
>>
>> Andreas
>>
>> [1] http://patches.openembedded.org/patch/24179/
>>
Koen Kooi - Aug. 4, 2012, 10:24 a.m.
Op 3 aug. 2012, om 22:19 heeft Laurentiu Palcu <laurentiu.palcu@intel.com> het volgende geschreven:

> This will improve first boot time because building the icon cache is
> done on host, with more processing power than the target.
> 
> Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>

Don't forget to send a patch with PR bumps for all recipes inheriting this class.
Laurentiu Palcu - Aug. 4, 2012, 2:01 p.m.
On 08/04/2012 12:29 PM, Andreas Müller wrote:
> On Sat, Aug 4, 2012 at 9:49 AM, Laurentiu Palcu
> <laurentiu.palcu@intel.com> wrote:
>>
>>
>> On 08/04/2012 02:22 AM, Andreas Müller wrote:
>>> On Fri, Aug 3, 2012 at 10:19 PM, Laurentiu Palcu
>>> <laurentiu.palcu@intel.com> wrote:
>>>> This will improve first boot time because building the icon cache is
>>>> done on host, with more processing power than the target.
>>>>
>>>> Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
>>>> ---
>>>>  meta/classes/gtk-icon-cache.bbclass |   10 ++--------
>>>>  1 file changed, 2 insertions(+), 8 deletions(-)
>>>>
>>>> diff --git a/meta/classes/gtk-icon-cache.bbclass b/meta/classes/gtk-icon-cache.bbclass
>>>> index 01fb2f3..2d82c54 100644
>>>> --- a/meta/classes/gtk-icon-cache.bbclass
>>>> +++ b/meta/classes/gtk-icon-cache.bbclass
>>>> @@ -1,18 +1,12 @@
>>>>  FILES_${PN} += "${datadir}/icons/hicolor"
>>>>
>>>> -DEPENDS += "${@['hicolor-icon-theme', '']['${BPN}' == 'hicolor-icon-theme']}"
>>>> +DEPENDS += "${@['hicolor-icon-theme', '']['${BPN}' == 'hicolor-icon-theme']} gtk+-native"
>>>>
>>>> -# This could run on the host as icon cache files are architecture independent,
>>>> -# but there is no gtk-update-icon-cache built natively.
>>>>  gtk_icon_cache_postinst() {
>>>> -if [ "x$D" != "x" ]; then
>>>> -        exit 1
>>>> -fi
>>>> -
>>>>  # Update the pixbuf loaders in case they haven't been registered yet
>>>>  GDK_PIXBUF_MODULEDIR=${libdir}/gdk-pixbuf-2.0/2.10.0/loaders gdk-pixbuf-query-loaders --update-cache
>>>>
>>>> -for icondir in /usr/share/icons/* ; do
>>>> +for icondir in $D/usr/share/icons/* ; do
>>>>      if [ -d $icondir ] ; then
>>>>          gtk-update-icon-cache -fqt  $icondir
>>>>      fi
>>>> --
>>>> 1.7.9.5
>>>>
>>> Long time ago there was a patch introducing gtk-icon-cache to be only
>>> run once on the machine [1] and I am still using that. At that time I
>>> was asked for a more generic approach. Now I ask:
>>>
>>> 1. Wouldn't it be better to have gtk-icon-cache run once even on host
>> But this is what these patches do. Make gtk-update-icon-cache run on
>> host, when the target rootfs is constructed, rather than running it on
>> target, at first boot.
> As far as I can see gtk-icon-cache is run for each package - how much
> extra build time at do_rootfs is to expect?
I didn't measure it. But I didn't notice do_roofts task taking a lot
more than it took previously. However, host machines these days have
lots of MHz under the hood, multiple cores and quite a lot of RAM,
compared to target machines. So, I do believe that waiting for some
extra tens of seconds at build time is a trade-off we can live with,
compared to waiting entire minutes for the target's first boot.

Thanks,
Laurentiu
> 
> Andreas
>>
>> Thanks,
>> Laurentiu
>>
>>> 2. Or better: How about a postinst 'runonce' framework for host/machine?
>>>
>>> Andreas
>>>
>>> [1] http://patches.openembedded.org/patch/24179/
>>>
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
Koen Kooi - Aug. 4, 2012, 5:14 p.m.
Op 4 aug. 2012, om 16:01 heeft Laurentiu Palcu <laurentiu.palcu@intel.com> het volgende geschreven:

> 
> 
> On 08/04/2012 12:29 PM, Andreas Müller wrote:
>> On Sat, Aug 4, 2012 at 9:49 AM, Laurentiu Palcu
>> <laurentiu.palcu@intel.com> wrote:
>>> 
>>> 
>>> On 08/04/2012 02:22 AM, Andreas Müller wrote:
>>>> On Fri, Aug 3, 2012 at 10:19 PM, Laurentiu Palcu
>>>> <laurentiu.palcu@intel.com> wrote:
>>>>> This will improve first boot time because building the icon cache is
>>>>> done on host, with more processing power than the target.
>>>>> 
>>>>> Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
>>>>> ---
>>>>> meta/classes/gtk-icon-cache.bbclass |   10 ++--------
>>>>> 1 file changed, 2 insertions(+), 8 deletions(-)
>>>>> 
>>>>> diff --git a/meta/classes/gtk-icon-cache.bbclass b/meta/classes/gtk-icon-cache.bbclass
>>>>> index 01fb2f3..2d82c54 100644
>>>>> --- a/meta/classes/gtk-icon-cache.bbclass
>>>>> +++ b/meta/classes/gtk-icon-cache.bbclass
>>>>> @@ -1,18 +1,12 @@
>>>>> FILES_${PN} += "${datadir}/icons/hicolor"
>>>>> 
>>>>> -DEPENDS += "${@['hicolor-icon-theme', '']['${BPN}' == 'hicolor-icon-theme']}"
>>>>> +DEPENDS += "${@['hicolor-icon-theme', '']['${BPN}' == 'hicolor-icon-theme']} gtk+-native"
>>>>> 
>>>>> -# This could run on the host as icon cache files are architecture independent,
>>>>> -# but there is no gtk-update-icon-cache built natively.
>>>>> gtk_icon_cache_postinst() {
>>>>> -if [ "x$D" != "x" ]; then
>>>>> -        exit 1
>>>>> -fi
>>>>> -
>>>>> # Update the pixbuf loaders in case they haven't been registered yet
>>>>> GDK_PIXBUF_MODULEDIR=${libdir}/gdk-pixbuf-2.0/2.10.0/loaders gdk-pixbuf-query-loaders --update-cache
>>>>> 
>>>>> -for icondir in /usr/share/icons/* ; do
>>>>> +for icondir in $D/usr/share/icons/* ; do
>>>>>     if [ -d $icondir ] ; then
>>>>>         gtk-update-icon-cache -fqt  $icondir
>>>>>     fi
>>>>> --
>>>>> 1.7.9.5
>>>>> 
>>>> Long time ago there was a patch introducing gtk-icon-cache to be only
>>>> run once on the machine [1] and I am still using that. At that time I
>>>> was asked for a more generic approach. Now I ask:
>>>> 
>>>> 1. Wouldn't it be better to have gtk-icon-cache run once even on host
>>> But this is what these patches do. Make gtk-update-icon-cache run on
>>> host, when the target rootfs is constructed, rather than running it on
>>> target, at first boot.
>> As far as I can see gtk-icon-cache is run for each package - how much
>> extra build time at do_rootfs is to expect?
> I didn't measure it. But I didn't notice do_roofts task taking a lot
> more than it took previously. However, host machines these days have
> lots of MHz under the hood, multiple cores and quite a lot of RAM,
> compared to target machines. So, I do believe that waiting for some
> extra tens of seconds at build time is a trade-off we can live with,
> compared to waiting entire minutes for the target's first boot.

it's about 90 minutes on first boot for beaglebone :)
Andreas Müller - Aug. 4, 2012, 7:37 p.m.
On Sat, Aug 4, 2012 at 7:14 PM, Koen Kooi <koen@dominion.thruhere.net> wrote:
>
> Op 4 aug. 2012, om 16:01 heeft Laurentiu Palcu <laurentiu.palcu@intel.com> het volgende geschreven:
>
>>
>>
>> On 08/04/2012 12:29 PM, Andreas Müller wrote:
>>> On Sat, Aug 4, 2012 at 9:49 AM, Laurentiu Palcu
>>> <laurentiu.palcu@intel.com> wrote:
>>>>
>>>>
>>>> On 08/04/2012 02:22 AM, Andreas Müller wrote:
>>>>> On Fri, Aug 3, 2012 at 10:19 PM, Laurentiu Palcu
>>>>> <laurentiu.palcu@intel.com> wrote:
>>>>>> This will improve first boot time because building the icon cache is
>>>>>> done on host, with more processing power than the target.
>>>>>>
>>>>>> Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
>>>>>> ---
>>>>>> meta/classes/gtk-icon-cache.bbclass |   10 ++--------
>>>>>> 1 file changed, 2 insertions(+), 8 deletions(-)
>>>>>>
>>>>>> diff --git a/meta/classes/gtk-icon-cache.bbclass b/meta/classes/gtk-icon-cache.bbclass
>>>>>> index 01fb2f3..2d82c54 100644
>>>>>> --- a/meta/classes/gtk-icon-cache.bbclass
>>>>>> +++ b/meta/classes/gtk-icon-cache.bbclass
>>>>>> @@ -1,18 +1,12 @@
>>>>>> FILES_${PN} += "${datadir}/icons/hicolor"
>>>>>>
>>>>>> -DEPENDS += "${@['hicolor-icon-theme', '']['${BPN}' == 'hicolor-icon-theme']}"
>>>>>> +DEPENDS += "${@['hicolor-icon-theme', '']['${BPN}' == 'hicolor-icon-theme']} gtk+-native"
>>>>>>
>>>>>> -# This could run on the host as icon cache files are architecture independent,
>>>>>> -# but there is no gtk-update-icon-cache built natively.
>>>>>> gtk_icon_cache_postinst() {
>>>>>> -if [ "x$D" != "x" ]; then
>>>>>> -        exit 1
>>>>>> -fi
>>>>>> -
>>>>>> # Update the pixbuf loaders in case they haven't been registered yet
>>>>>> GDK_PIXBUF_MODULEDIR=${libdir}/gdk-pixbuf-2.0/2.10.0/loaders gdk-pixbuf-query-loaders --update-cache
>>>>>>
>>>>>> -for icondir in /usr/share/icons/* ; do
>>>>>> +for icondir in $D/usr/share/icons/* ; do
>>>>>>     if [ -d $icondir ] ; then
>>>>>>         gtk-update-icon-cache -fqt  $icondir
>>>>>>     fi
>>>>>> --
>>>>>> 1.7.9.5
>>>>>>
>>>>> Long time ago there was a patch introducing gtk-icon-cache to be only
>>>>> run once on the machine [1] and I am still using that. At that time I
>>>>> was asked for a more generic approach. Now I ask:
>>>>>
>>>>> 1. Wouldn't it be better to have gtk-icon-cache run once even on host
>>>> But this is what these patches do. Make gtk-update-icon-cache run on
>>>> host, when the target rootfs is constructed, rather than running it on
>>>> target, at first boot.
>>> As far as I can see gtk-icon-cache is run for each package - how much
>>> extra build time at do_rootfs is to expect?
>> I didn't measure it. But I didn't notice do_roofts task taking a lot
>> more than it took previously. However, host machines these days have
>> lots of MHz under the hood, multiple cores and quite a lot of RAM,
>> compared to target machines. So, I do believe that waiting for some
>> extra tens of seconds at build time is a trade-off we can live with,
>> compared to waiting entire minutes for the target's first boot.
>
> it's about 90 minutes on first boot for beaglebone :)

And less than 3min on overo with the patches we sent (and my xfce
image is full of gtk-icon-update). Don't misunderstand me: I agree on
doing things like this on host if possible. But for me the main time
waiting on a new image is do_rootfs and I just suggest to think about
having these tasks run only once - but we can do this later or never.
A bit off topic: As far as I can remember there were times when it was
a no-go having gtk-native in oe-core. I hope they are over...

Andreas
Khem Raj - Aug. 4, 2012, 7:51 p.m.
On Sat, Aug 4, 2012 at 12:37 PM, Andreas Müller
<schnitzeltony@googlemail.com> wrote:
> And less than 3min on overo with the patches we sent (and my xfce
> image is full of gtk-icon-update). Don't misunderstand me: I agree on
> doing things like this on host if possible. But for me the main time
> waiting on a new image is do_rootfs and I just suggest to think about
> having these tasks run only once - but we can do this later or never.
> A bit off topic: As far as I can remember there were times when it was
> a no-go having gtk-native in oe-core. I hope they are over...

I certainly agree with you that it should be run once. However what if
you changed something in icons between towo do rootfs runs ?
but I would like to know how much build time is it adding to do_rootfs ?
sometimes over optimising is bad too.
Martin Jansa - Aug. 4, 2012, 7:56 p.m.
On Sat, Aug 04, 2012 at 12:51:47PM -0700, Khem Raj wrote:
> On Sat, Aug 4, 2012 at 12:37 PM, Andreas Müller
> <schnitzeltony@googlemail.com> wrote:
> > And less than 3min on overo with the patches we sent (and my xfce
> > image is full of gtk-icon-update). Don't misunderstand me: I agree on
> > doing things like this on host if possible. But for me the main time
> > waiting on a new image is do_rootfs and I just suggest to think about
> > having these tasks run only once - but we can do this later or never.
> > A bit off topic: As far as I can remember there were times when it was
> > a no-go having gtk-native in oe-core. I hope they are over...
> 
> I certainly agree with you that it should be run once. However what if
> you changed something in icons between towo do rootfs runs ?
> but I would like to know how much build time is it adding to do_rootfs ?
> sometimes over optimising is bad too.

I think Andreas patch does run it once *per* do_rootfs, so not for every
package which uses it if there is at least one installed in do_rootfs
then it's executed once.
Andreas Müller - Aug. 4, 2012, 8:25 p.m.
On Sat, Aug 4, 2012 at 9:56 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
> On Sat, Aug 04, 2012 at 12:51:47PM -0700, Khem Raj wrote:
>> On Sat, Aug 4, 2012 at 12:37 PM, Andreas Müller
>> <schnitzeltony@googlemail.com> wrote:
>> > And less than 3min on overo with the patches we sent (and my xfce
>> > image is full of gtk-icon-update). Don't misunderstand me: I agree on
>> > doing things like this on host if possible. But for me the main time
>> > waiting on a new image is do_rootfs and I just suggest to think about
>> > having these tasks run only once - but we can do this later or never.
>> > A bit off topic: As far as I can remember there were times when it was
>> > a no-go having gtk-native in oe-core. I hope they are over...
>>
>> I certainly agree with you that it should be run once. However what if
>> you changed something in icons between towo do rootfs runs ?
>> but I would like to know how much build time is it adding to do_rootfs ?
>> sometimes over optimising is bad too.
Good point I totally forgot (the old approach worked correct for that).
I come back to my first post on this: I would like to see some more
generic runonce approach...
>
> I think Andreas patch does run it once *per* do_rootfs, so not for every
> package which uses it if there is at least one installed in do_rootfs
> then it's executed once.
>
Andreas
Koen Kooi - Aug. 5, 2012, 11:50 a.m.
Op 4 aug. 2012, om 21:37 heeft Andreas Müller <schnitzeltony@googlemail.com> het volgende geschreven:

> On Sat, Aug 4, 2012 at 7:14 PM, Koen Kooi <koen@dominion.thruhere.net> wrote:
>> 
>> Op 4 aug. 2012, om 16:01 heeft Laurentiu Palcu <laurentiu.palcu@intel.com> het volgende geschreven:
>> 
>>> 
>>> 
>>> On 08/04/2012 12:29 PM, Andreas Müller wrote:
>>>> On Sat, Aug 4, 2012 at 9:49 AM, Laurentiu Palcu
>>>> <laurentiu.palcu@intel.com> wrote:
>>>>> 
>>>>> 
>>>>> On 08/04/2012 02:22 AM, Andreas Müller wrote:
>>>>>> On Fri, Aug 3, 2012 at 10:19 PM, Laurentiu Palcu
>>>>>> <laurentiu.palcu@intel.com> wrote:
>>>>>>> This will improve first boot time because building the icon cache is
>>>>>>> done on host, with more processing power than the target.
>>>>>>> 
>>>>>>> Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
>>>>>>> ---
>>>>>>> meta/classes/gtk-icon-cache.bbclass |   10 ++--------
>>>>>>> 1 file changed, 2 insertions(+), 8 deletions(-)
>>>>>>> 
>>>>>>> diff --git a/meta/classes/gtk-icon-cache.bbclass b/meta/classes/gtk-icon-cache.bbclass
>>>>>>> index 01fb2f3..2d82c54 100644
>>>>>>> --- a/meta/classes/gtk-icon-cache.bbclass
>>>>>>> +++ b/meta/classes/gtk-icon-cache.bbclass
>>>>>>> @@ -1,18 +1,12 @@
>>>>>>> FILES_${PN} += "${datadir}/icons/hicolor"
>>>>>>> 
>>>>>>> -DEPENDS += "${@['hicolor-icon-theme', '']['${BPN}' == 'hicolor-icon-theme']}"
>>>>>>> +DEPENDS += "${@['hicolor-icon-theme', '']['${BPN}' == 'hicolor-icon-theme']} gtk+-native"
>>>>>>> 
>>>>>>> -# This could run on the host as icon cache files are architecture independent,
>>>>>>> -# but there is no gtk-update-icon-cache built natively.
>>>>>>> gtk_icon_cache_postinst() {
>>>>>>> -if [ "x$D" != "x" ]; then
>>>>>>> -        exit 1
>>>>>>> -fi
>>>>>>> -
>>>>>>> # Update the pixbuf loaders in case they haven't been registered yet
>>>>>>> GDK_PIXBUF_MODULEDIR=${libdir}/gdk-pixbuf-2.0/2.10.0/loaders gdk-pixbuf-query-loaders --update-cache
>>>>>>> 
>>>>>>> -for icondir in /usr/share/icons/* ; do
>>>>>>> +for icondir in $D/usr/share/icons/* ; do
>>>>>>>    if [ -d $icondir ] ; then
>>>>>>>        gtk-update-icon-cache -fqt  $icondir
>>>>>>>    fi
>>>>>>> --
>>>>>>> 1.7.9.5
>>>>>>> 
>>>>>> Long time ago there was a patch introducing gtk-icon-cache to be only
>>>>>> run once on the machine [1] and I am still using that. At that time I
>>>>>> was asked for a more generic approach. Now I ask:
>>>>>> 
>>>>>> 1. Wouldn't it be better to have gtk-icon-cache run once even on host
>>>>> But this is what these patches do. Make gtk-update-icon-cache run on
>>>>> host, when the target rootfs is constructed, rather than running it on
>>>>> target, at first boot.
>>>> As far as I can see gtk-icon-cache is run for each package - how much
>>>> extra build time at do_rootfs is to expect?
>>> I didn't measure it. But I didn't notice do_roofts task taking a lot
>>> more than it took previously. However, host machines these days have
>>> lots of MHz under the hood, multiple cores and quite a lot of RAM,
>>> compared to target machines. So, I do believe that waiting for some
>>> extra tens of seconds at build time is a trade-off we can live with,
>>> compared to waiting entire minutes for the target's first boot.
>> 
>> it's about 90 minutes on first boot for beaglebone :)
> 
> And less than 3min on overo with the patches we sent (and my xfce
> image is full of gtk-icon-update). Don't misunderstand me: I agree on
> doing things like this on host if possible. But for me the main time
> waiting on a new image is do_rootfs and I just suggest to think about
> having these tasks run only once - but we can do this later or never.
> A bit off topic: As far as I can remember there were times when it was
> a no-go having gtk-native in oe-core. I hope they are over...

I never bought the arguments against gtk-native, so I hope common sense prevails and we can do the icon-cache stuff on the host.

Patch

diff --git a/meta/classes/gtk-icon-cache.bbclass b/meta/classes/gtk-icon-cache.bbclass
index 01fb2f3..2d82c54 100644
--- a/meta/classes/gtk-icon-cache.bbclass
+++ b/meta/classes/gtk-icon-cache.bbclass
@@ -1,18 +1,12 @@ 
 FILES_${PN} += "${datadir}/icons/hicolor"
 
-DEPENDS += "${@['hicolor-icon-theme', '']['${BPN}' == 'hicolor-icon-theme']}"
+DEPENDS += "${@['hicolor-icon-theme', '']['${BPN}' == 'hicolor-icon-theme']} gtk+-native"
 
-# This could run on the host as icon cache files are architecture independent,
-# but there is no gtk-update-icon-cache built natively.
 gtk_icon_cache_postinst() {
-if [ "x$D" != "x" ]; then
-        exit 1
-fi
-
 # Update the pixbuf loaders in case they haven't been registered yet
 GDK_PIXBUF_MODULEDIR=${libdir}/gdk-pixbuf-2.0/2.10.0/loaders gdk-pixbuf-query-loaders --update-cache
 
-for icondir in /usr/share/icons/* ; do
+for icondir in $D/usr/share/icons/* ; do
     if [ -d $icondir ] ; then
         gtk-update-icon-cache -fqt  $icondir
     fi