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

login
register
mail settings
Submitter Laurentiu Palcu
Date Aug. 5, 2012, 4:58 p.m.
Message ID <501EA63F.9090304@intel.com>
Download mbox | patch
Permalink /patch/33901/
State New
Headers show

Comments

Laurentiu Palcu - Aug. 5, 2012, 4:58 p.m.
On 08/04/2012 10:51 PM, 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 ?
Short answer: *less than 2 secs*

Long answer:
In order to measure the time added to do_rootfs by the
gtk-update-icon-cache calls, I modified gtk+ recipe to create a wrapper
script, as seen in attachment [1].

I compiled core-image-sato using the following setup:

CPU: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 4 cores with HT
RAM: 8GB
Storage: SSD

The measurements are in attachment [2].

Conclusion: I would say that a delay of less than 2 seconds added to
do_rootfs is not that bad, in my opinion. Of course, we can optimize
this as much as possible but, is it worth the effort?

You could give it a test yourselves and let me know your results. I will
send a version 2 of the patchset(as soon as we all agree on the
solution), with some changes suggested by Mark and some PR bumps
suggested by Koen.

[1] - measure_time.patch
[2] - do_rootfs.log

Thanks,
Laurentiu

> sometimes over optimising is bad too.
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
Andreas Müller - Aug. 5, 2012, 10:30 p.m.
On Sun, Aug 5, 2012 at 6:58 PM, Laurentiu Palcu
<laurentiu.palcu@intel.com> wrote:
> You could give it a test yourselves and let me know your results. I will
> send a version 2 of the patchset(as soon as we all agree on the
> solution), with some changes suggested by Mark and some PR bumps
> suggested by Koen.
With the image I usually work with [1] and AMD Phenom II X6 1090 16GB
RAM I get a measurable delay - see attachment. I would not be happy
loosing latest do_rootfs enhancements (off topic - thanks for that).
Remeber we are only talking of gtk-update-icon-cache. OK I could buy
an intel host and work just with sato images but...

Andreas

[1] https://gitorious.org/schnitzeltony-oe-meta/meta-misc/blobs/master/recipes-image/xfce-full-image.bb
Andreas Müller - Aug. 5, 2012, 10:49 p.m.
On Mon, Aug 6, 2012 at 12:30 AM, Andreas Müller
<schnitzeltony@googlemail.com> wrote:
> On Sun, Aug 5, 2012 at 6:58 PM, Laurentiu Palcu
> <laurentiu.palcu@intel.com> wrote:
>> You could give it a test yourselves and let me know your results. I will
>> send a version 2 of the patchset(as soon as we all agree on the
>> solution), with some changes suggested by Mark and some PR bumps
>> suggested by Koen.
> With the image I usually work with [1] and AMD Phenom II X6 1090 16GB
> RAM I get a measurable delay - see attachment. I would not be happy
> loosing latest do_rootfs enhancements (off topic - thanks for that).
> Remeber we are only talking of gtk-update-icon-cache. OK I could buy
> an intel host and work just with sato images but...
>
> Andreas
>
> [1] https://gitorious.org/schnitzeltony-oe-meta/meta-misc/blobs/master/recipes-image/xfce-full-image.bb
OK I know it is not that important: The image created with this patch
series creates tons of messages like

xfdesktop:446): GdkPixbuf-WARNING **: Cannot open pixbuf loader module
file '/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache': No such file or
directory

and don't have icons at all. Did you run test that (on a hardware
plattform different to your host)?

Andreas
Laurentiu Palcu - Aug. 6, 2012, 7:48 a.m.
On 08/06/2012 01:49 AM, Andreas Müller wrote:
> On Mon, Aug 6, 2012 at 12:30 AM, Andreas Müller
> <schnitzeltony@googlemail.com> wrote:
>> On Sun, Aug 5, 2012 at 6:58 PM, Laurentiu Palcu
>> <laurentiu.palcu@intel.com> wrote:
>>> You could give it a test yourselves and let me know your results. I will
>>> send a version 2 of the patchset(as soon as we all agree on the
>>> solution), with some changes suggested by Mark and some PR bumps
>>> suggested by Koen.
>> With the image I usually work with [1] and AMD Phenom II X6 1090 16GB
>> RAM I get a measurable delay - see attachment. I would not be happy
>> loosing latest do_rootfs enhancements (off topic - thanks for that).
>> Remeber we are only talking of gtk-update-icon-cache. OK I could buy
>> an intel host and work just with sato images but...
I suppose you could, but nobody asked you to do that, it's your choice
what's your build machine or what you'll be building for.

Thanks for the measurements though. They do, indeed, show quite a
significant amount of time (around 6 minutes). A run-once solution is to
be considered in this case.

>>
>> Andreas
>>
>> [1] https://gitorious.org/schnitzeltony-oe-meta/meta-misc/blobs/master/recipes-image/xfce-full-image.bb
> OK I know it is not that important: The image created with this patch
> series creates tons of messages like
Why do you think is not important. Please elaborate. Or is it irony? I
don't think is in anybody's benefit if you take this approach. :) All
errors/warnings are important and they have to be taken care of.

> 
> xfdesktop:446): GdkPixbuf-WARNING **: Cannot open pixbuf loader module
> file '/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache': No such file or
> directory
> 
> and don't have icons at all. Did you run test that (on a hardware
> plattform different to your host)?
I only tested on qemu. And it worked just fine, without any errors. With
all icons in place.
> 
> Andreas
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
Andreas Müller - Aug. 6, 2012, 8:10 a.m.
On Mon, Aug 6, 2012 at 9:48 AM, Laurentiu Palcu
<laurentiu.palcu@intel.com> wrote:
>
>
> On 08/06/2012 01:49 AM, Andreas Müller wrote:
>> On Mon, Aug 6, 2012 at 12:30 AM, Andreas Müller
>> <schnitzeltony@googlemail.com> wrote:
>>> On Sun, Aug 5, 2012 at 6:58 PM, Laurentiu Palcu
>>> <laurentiu.palcu@intel.com> wrote:
>>>> You could give it a test yourselves and let me know your results. I will
>>>> send a version 2 of the patchset(as soon as we all agree on the
>>>> solution), with some changes suggested by Mark and some PR bumps
>>>> suggested by Koen.
>>> With the image I usually work with [1] and AMD Phenom II X6 1090 16GB
>>> RAM I get a measurable delay - see attachment. I would not be happy
>>> loosing latest do_rootfs enhancements (off topic - thanks for that).
>>> Remeber we are only talking of gtk-update-icon-cache. OK I could buy
>>> an intel host and work just with sato images but...
> I suppose you could, but nobody asked you to do that, it's your choice
> what's your build machine or what you'll be building for.
>
> Thanks for the measurements though. They do, indeed, show quite a
> significant amount of time (around 6 minutes). A run-once solution is to
> be considered in this case.
>
>>>
>>> Andreas
>>>
>>> [1] https://gitorious.org/schnitzeltony-oe-meta/meta-misc/blobs/master/recipes-image/xfce-full-image.bb
>> OK I know it is not that important: The image created with this patch
>> series creates tons of messages like
> Why do you think is not important. Please elaborate. Or is it irony?
Yes sorry - it was late night.
> I don't think is in anybody's benefit if you take this approach. :) All
> errors/warnings are important and they have to be taken care of.
>
>>
>> xfdesktop:446): GdkPixbuf-WARNING **: Cannot open pixbuf loader module
>> file '/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache': No such file or
>> directory
>>
>> and don't have icons at all. Did you run test that (on a hardware
>> plattform different to your host)?
> I only tested on qemu. And it worked just fine, without any errors. With
> all icons in place.
Which hardware did you emulate? My tests were done for overo (ARM
cortext A8). I wonder if the created database is machine specific.

Andreas
Laurentiu Palcu - Aug. 6, 2012, 9:18 a.m.
On 08/06/2012 11:10 AM, Andreas Müller wrote:
> On Mon, Aug 6, 2012 at 9:48 AM, Laurentiu Palcu
> <laurentiu.palcu@intel.com> wrote:
>>
>>
>> On 08/06/2012 01:49 AM, Andreas Müller wrote:
>>> On Mon, Aug 6, 2012 at 12:30 AM, Andreas Müller
>>> <schnitzeltony@googlemail.com> wrote:
>>>> On Sun, Aug 5, 2012 at 6:58 PM, Laurentiu Palcu
>>>> <laurentiu.palcu@intel.com> wrote:
>>>>> You could give it a test yourselves and let me know your results. I will
>>>>> send a version 2 of the patchset(as soon as we all agree on the
>>>>> solution), with some changes suggested by Mark and some PR bumps
>>>>> suggested by Koen.
>>>> With the image I usually work with [1] and AMD Phenom II X6 1090 16GB
>>>> RAM I get a measurable delay - see attachment. I would not be happy
>>>> loosing latest do_rootfs enhancements (off topic - thanks for that).
>>>> Remeber we are only talking of gtk-update-icon-cache. OK I could buy
>>>> an intel host and work just with sato images but...
>> I suppose you could, but nobody asked you to do that, it's your choice
>> what's your build machine or what you'll be building for.
>>
>> Thanks for the measurements though. They do, indeed, show quite a
>> significant amount of time (around 6 minutes). A run-once solution is to
>> be considered in this case.
>>
>>>>
>>>> Andreas
>>>>
>>>> [1] https://gitorious.org/schnitzeltony-oe-meta/meta-misc/blobs/master/recipes-image/xfce-full-image.bb
>>> OK I know it is not that important: The image created with this patch
>>> series creates tons of messages like
>> Why do you think is not important. Please elaborate. Or is it irony?
> Yes sorry - it was late night.
It's OK, let's work together and find the best solution for all of us. I
would also be pissed of if I had to wait an extra 6 minutes every
do_rootfs run.

>> I don't think is in anybody's benefit if you take this approach. :) All
>> errors/warnings are important and they have to be taken care of.
>>
>>>
>>> xfdesktop:446): GdkPixbuf-WARNING **: Cannot open pixbuf loader module
>>> file '/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache': No such file or
>>> directory
>>>
>>> and don't have icons at all. Did you run test that (on a hardware
>>> plattform different to your host)?
>> I only tested on qemu. And it worked just fine, without any errors. With
>> all icons in place.
> Which hardware did you emulate? My tests were done for overo (ARM
> cortext A8). I wonder if the created database is machine specific.
I used qemuarm. As far as I know, the database shouldn't be machine
specific. And, looking at the log you sent, it looks like all commands
succeeded. Otherwise, the 'time' application would also signal in the
log file if the command failed. Could please have a look, on your host
(xfce-full-image-1.0-r0/rootfs/usr/share/icons/hicolor or
xfce-full-image-1.0-r0/rootfs/usr/share/icons/gnome), to see if it
creates the icon-theme.cache files? It does for me and I don't
understand why it doesn't in your case...

Thanks,
Laurentiu

> 
> Andreas
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
Ross Burton - Aug. 6, 2012, 9:35 a.m.
On 6 August 2012 10:18, Laurentiu Palcu <laurentiu.palcu@intel.com> wrote:
>> Which hardware did you emulate? My tests were done for overo (ARM
>> cortext A8). I wonder if the created database is machine specific.

> I used qemuarm. As far as I know, the database shouldn't be machine
> specific.

Looking at updateiconcache.c, all of the functions that write data to
the cache file use write_card16, write_card32 and so on which convert
to big-endian.  Unless there's a bug hidden away, the cache files are
cross-platform.

Ross
Andreas Müller - Aug. 6, 2012, 9:36 a.m.
On Mon, Aug 6, 2012 at 11:18 AM, Laurentiu Palcu
<laurentiu.palcu@intel.com> wrote:
>
>
> On 08/06/2012 11:10 AM, Andreas Müller wrote:
>> On Mon, Aug 6, 2012 at 9:48 AM, Laurentiu Palcu
>> <laurentiu.palcu@intel.com> wrote:
>>>
>>>
>>> On 08/06/2012 01:49 AM, Andreas Müller wrote:
>>>> On Mon, Aug 6, 2012 at 12:30 AM, Andreas Müller
>>>> <schnitzeltony@googlemail.com> wrote:
>>>>> On Sun, Aug 5, 2012 at 6:58 PM, Laurentiu Palcu
>>>>> <laurentiu.palcu@intel.com> wrote:
>>>>>> You could give it a test yourselves and let me know your results. I will
>>>>>> send a version 2 of the patchset(as soon as we all agree on the
>>>>>> solution), with some changes suggested by Mark and some PR bumps
>>>>>> suggested by Koen.
>>>>> With the image I usually work with [1] and AMD Phenom II X6 1090 16GB
>>>>> RAM I get a measurable delay - see attachment. I would not be happy
>>>>> loosing latest do_rootfs enhancements (off topic - thanks for that).
>>>>> Remeber we are only talking of gtk-update-icon-cache. OK I could buy
>>>>> an intel host and work just with sato images but...
>>> I suppose you could, but nobody asked you to do that, it's your choice
>>> what's your build machine or what you'll be building for.
>>>
>>> Thanks for the measurements though. They do, indeed, show quite a
>>> significant amount of time (around 6 minutes). A run-once solution is to
>>> be considered in this case.
>>>
>>>>>
>>>>> Andreas
>>>>>
>>>>> [1] https://gitorious.org/schnitzeltony-oe-meta/meta-misc/blobs/master/recipes-image/xfce-full-image.bb
>>>> OK I know it is not that important: The image created with this patch
>>>> series creates tons of messages like
>>> Why do you think is not important. Please elaborate. Or is it irony?
>> Yes sorry - it was late night.
> It's OK, let's work together and find the best solution for all of us. I
> would also be pissed of if I had to wait an extra 6 minutes every
> do_rootfs run.
>
>>> I don't think is in anybody's benefit if you take this approach. :) All
>>> errors/warnings are important and they have to be taken care of.
>>>
>>>>
>>>> xfdesktop:446): GdkPixbuf-WARNING **: Cannot open pixbuf loader module
>>>> file '/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache': No such file or
>>>> directory
>>>>
>>>> and don't have icons at all. Did you run test that (on a hardware
>>>> plattform different to your host)?
>>> I only tested on qemu. And it worked just fine, without any errors. With
>>> all icons in place.
>> Which hardware did you emulate? My tests were done for overo (ARM
>> cortext A8). I wonder if the created database is machine specific.
> I used qemuarm. As far as I know, the database shouldn't be machine
> specific. And, looking at the log you sent, it looks like all commands
> succeeded. Otherwise, the 'time' application would also signal in the
> log file if the command failed. Could please have a look, on your host
> (xfce-full-image-1.0-r0/rootfs/usr/share/icons/hicolor or
> xfce-full-image-1.0-r0/rootfs/usr/share/icons/gnome), to see if it
> creates the icon-theme.cache files? It does for me and I don't
> understand why it doesn't in your case...
>
I will check today evening since the machine with this data is at home...

Andreas
Andreas Müller - Aug. 6, 2012, 6:50 p.m.
On Mon, Aug 6, 2012 at 11:18 AM, Laurentiu Palcu
<laurentiu.palcu@intel.com> wrote:
>
>
> On 08/06/2012 11:10 AM, Andreas Müller wrote:
>> On Mon, Aug 6, 2012 at 9:48 AM, Laurentiu Palcu
>> <laurentiu.palcu@intel.com> wrote:
>>>
>>>
>>> On 08/06/2012 01:49 AM, Andreas Müller wrote:
>>>> On Mon, Aug 6, 2012 at 12:30 AM, Andreas Müller
>>>> <schnitzeltony@googlemail.com> wrote:
>>>>> On Sun, Aug 5, 2012 at 6:58 PM, Laurentiu Palcu
>>>>> <laurentiu.palcu@intel.com> wrote:
>>>>>> You could give it a test yourselves and let me know your results. I will
>>>>>> send a version 2 of the patchset(as soon as we all agree on the
>>>>>> solution), with some changes suggested by Mark and some PR bumps
>>>>>> suggested by Koen.
>>>>> With the image I usually work with [1] and AMD Phenom II X6 1090 16GB
>>>>> RAM I get a measurable delay - see attachment. I would not be happy
>>>>> loosing latest do_rootfs enhancements (off topic - thanks for that).
>>>>> Remeber we are only talking of gtk-update-icon-cache. OK I could buy
>>>>> an intel host and work just with sato images but...
>>> I suppose you could, but nobody asked you to do that, it's your choice
>>> what's your build machine or what you'll be building for.
>>>
>>> Thanks for the measurements though. They do, indeed, show quite a
>>> significant amount of time (around 6 minutes). A run-once solution is to
>>> be considered in this case.
>>>
>>>>>
>>>>> Andreas
>>>>>
>>>>> [1] https://gitorious.org/schnitzeltony-oe-meta/meta-misc/blobs/master/recipes-image/xfce-full-image.bb
>>>> OK I know it is not that important: The image created with this patch
>>>> series creates tons of messages like
>>> Why do you think is not important. Please elaborate. Or is it irony?
>> Yes sorry - it was late night.
> It's OK, let's work together and find the best solution for all of us. I
> would also be pissed of if I had to wait an extra 6 minutes every
> do_rootfs run.
>
>>> I don't think is in anybody's benefit if you take this approach. :) All
>>> errors/warnings are important and they have to be taken care of.
>>>
>>>>
>>>> xfdesktop:446): GdkPixbuf-WARNING **: Cannot open pixbuf loader module
>>>> file '/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache': No such file or
>>>> directory
>>>>
>>>> and don't have icons at all. Did you run test that (on a hardware
>>>> plattform different to your host)?
>>> I only tested on qemu. And it worked just fine, without any errors. With
>>> all icons in place.
>> Which hardware did you emulate? My tests were done for overo (ARM
>> cortext A8). I wonder if the created database is machine specific.
> I used qemuarm. As far as I know, the database shouldn't be machine
> specific. And, looking at the log you sent, it looks like all commands
> succeeded. Otherwise, the 'time' application would also signal in the
> log file if the command failed. Could please have a look, on your host
> (xfce-full-image-1.0-r0/rootfs/usr/share/icons/hicolor or
> xfce-full-image-1.0-r0/rootfs/usr/share/icons/gnome), to see if it
> creates the icon-theme.cache files? It does for me and I don't
> understand why it doesn't in your case...
>
> Thanks,
> Laurentiu
>
I checked: In both I find the files icon-theme.cache.

Andreas

Patch

diff --git a/meta/recipes-gnome/gtk+/gtk+_2.24.8.bb b/meta/recipes-gnome/gtk+/gtk+_2.24.8.bb
index 878eb87..e77ecce 100644
--- a/meta/recipes-gnome/gtk+/gtk+_2.24.8.bb
+++ b/meta/recipes-gnome/gtk+/gtk+_2.24.8.bb
@@ -41,6 +41,18 @@  BBCLASSEXTEND = "native"
 RRECOMMENDS_${PN}_virtclass-native = ""
 DEPENDS_virtclass-native = "glib-2.0-native atk-native pango-native cairo-native gdk-pixbuf-native"
 
+do_install_append_virtclass-native () {
+    mv ${D}/${bindir}/gtk-update-icon-cache ${D}/${bindir}/gtk-update-icon-cache.real
+
+    cat << "EOF" > ${D}/${bindir}/gtk-update-icon-cache
+#!/bin/bash
+
+echo "Executing: gtk-update-icon-cache $@" >> ${TMPDIR}/do_rootfs.log
+/usr/bin/time --f "real:%e user:%U sys:%S" -o ${TMPDIR}/do_rootfs.log --append gtk-update-icon-cache.real $@
+EOF
+    chmod +x ${D}/${bindir}/gtk-update-icon-cache
+}
+
 python populate_packages_prepend () {
     prologue = d.getVar("postinst_prologue", True)