[PATCH 0/5] Run postinst scriptlets at do_rootfs time

[PATCH 0/5] Run postinst scriptlets at do_rootfs time

[Laurentiu Palcu]

Hi,

This first patchset is part of series that will move as many postinst operations as
possible to the do_rootfs time, hence, taking advantage of the processing power of
the host and reduce target's first boot time. This patchset, in particular, is
focused on gtk-update-icon-cache:  which can be very time consuming on
slow machines.

Thanks,
Laurentiu

The following changes since commit ed6beed4b309c5d9ccaa88e620ea27e5ee045757:

  gcc: Bump PR since there have been several gcc changes and various problems reported and this should flush anything stale out (2012-08-03 10:32:35 +0100)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib lpalcu/postinst
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=lpalcu/postinst

Laurentiu Palcu (5):
  gtk+: enable gtk+-native
  sato-icon-theme: make postinst scriplet run at do_rootfs time
  package_rpm: export the native directory to the postinst scriptlets
  gtk-icon-cache: call postinst scriplet at do_rootfs time
  gdk-pixbuf: allow postinst scriplet to be called at do_rootfs time

 meta/classes/gtk-icon-cache.bbclass                |   10 ++--------
 meta/classes/package_rpm.bbclass                   |    1 +
 meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.24.1.bb |    6 ++++--
 meta/recipes-gnome/gtk+/gtk+_2.24.8.bb             |    5 ++++-
 .../sato-icon-theme/sato-icon-theme.inc            |   10 +++++-----
 5 files changed, 16 insertions(+), 16 deletions(-)

-- 
1.7.9.5

[PATCH 1/5] gtk+: enable gtk+-native

[Laurentiu Palcu]

This is needed in order to run postinst scriplets at do_rootfs time
rather than first boot time.

Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
---
 meta/recipes-gnome/gtk+/gtk+_2.24.8.bb |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-gnome/gtk+/gtk+_2.24.8.bb b/meta/recipes-gnome/gtk+/gtk+_2.24.8.bb
index 529f8e1..878eb87 100644
--- a/meta/recipes-gnome/gtk+/gtk+_2.24.8.bb
+++ b/meta/recipes-gnome/gtk+/gtk+_2.24.8.bb
@@ -27,7 +27,7 @@ SRC_URI = "http://download.gnome.org/sources/gtk+/2.24/gtk+-${PV}.tar.bz2 \
 #        file://combo-arrow-size.patch;striplevel=0
 #            file://configurefix.patch
 
-PR = "r5"
+PR = "r6"
 
 SRC_URI[md5sum] = "0413187f7e596aef00ccd1b54776ff03"
 SRC_URI[sha256sum] = "ac2325a65312922a6722a7c02a389f3f4072d79e13131485cc7b7226e2537043"
@@ -37,6 +37,9 @@ EXTRA_OECONF = "--without-libtiff --without-libjasper --enable-xkb --disable-gli
 LIBV = "2.10.0"
 
 PACKAGES_DYNAMIC += "gtk-immodule-* gtk-printbackend-*"
+BBCLASSEXTEND = "native"
+RRECOMMENDS_${PN}_virtclass-native = ""
+DEPENDS_virtclass-native = "glib-2.0-native atk-native pango-native cairo-native gdk-pixbuf-native"
 
 python populate_packages_prepend () {
     prologue = d.getVar("postinst_prologue", True)
-- 
1.7.9.5

[PATCH 2/5] sato-icon-theme: make postinst scriplet run at do_rootfs time

[Laurentiu Palcu]

Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
---
 .../sato-icon-theme/sato-icon-theme.inc            |   10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/meta/recipes-sato/sato-icon-theme/sato-icon-theme.inc b/meta/recipes-sato/sato-icon-theme/sato-icon-theme.inc
index 9fd1012..ba15514 100644
--- a/meta/recipes-sato/sato-icon-theme/sato-icon-theme.inc
+++ b/meta/recipes-sato/sato-icon-theme/sato-icon-theme.inc
@@ -6,7 +6,7 @@ LICENSE = "CC-BY-SA-3.0"
 LIC_FILES_CHKSUM = "file://COPYING;md5=56a830bbe6e4697fe6cbbae01bb7c2b2"
 
 SECTION = "x11"
-DEPENDS = ""
+DEPENDS = "gtk+-native"
 
 inherit autotools pkgconfig allarch
 
@@ -17,9 +17,9 @@ EXTRA_OECONF += "--with-iconmap=${STAGING_LIBDIR_NATIVE}/../libexec/icon-name-ma
 #explictly setting "Sato" as default icon theme to avoid icon missing due to
 #tricky race condition
 pkg_postinst_${PN} () {
-        if [ "x$D" != "x" ]; then
-                exit 1
+        gtk-update-icon-cache -q $D/usr/share/icons/Sato
+        if [ ! -d $D/etc/gtk-2.0 ]; then
+            mkdir -p $D/etc/gtk-2.0
         fi
-        gtk-update-icon-cache -q /usr/share/icons/Sato
-        echo 'gtk-icon-theme-name = "Sato"' >> /etc/gtk-2.0/gtkrc
+        echo 'gtk-icon-theme-name = "Sato"' >> $D/etc/gtk-2.0/gtkrc
 }
-- 
1.7.9.5

Re: [PATCH 2/5] sato-icon-theme: make postinst scriplet run at do_rootfs time

[Burton, Ross]

On 3 August 2012 21:19, Laurentiu Palcu <laurentiu.palcu@intel.com> wrote:
>  pkg_postinst_${PN} () {
> -        if [ "x$D" != "x" ]; then
> -                exit 1
> +        gtk-update-icon-cache -q $D/usr/share/icons/Sato
> +        if [ ! -d $D/etc/gtk-2.0 ]; then
> +            mkdir -p $D/etc/gtk-2.0
>          fi
> -        gtk-update-icon-cache -q /usr/share/icons/Sato
> -        echo 'gtk-icon-theme-name = "Sato"' >> /etc/gtk-2.0/gtkrc
> +        echo 'gtk-icon-theme-name = "Sato"' >> $D/etc/gtk-2.0/gtkrc
>  }

Surely sato-icon-theme should be inheriting the gtk-icon-cache class
to remove all of the duplicated logic?

Ross

[PATCH 3/5] package_rpm: export the native directory to the postinst scriptlets

[Laurentiu Palcu]

Some postinst scriptlets test for the existence of certain files but
have the paths hardcoded to the target's rootfs. This patch will allow
us to run postinst scriptlets at do_rootfs time by calling native
binaries.

Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
---
 meta/classes/package_rpm.bbclass |    1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/classes/package_rpm.bbclass b/meta/classes/package_rpm.bbclass
index 50e9b31..113b19c 100644
--- a/meta/classes/package_rpm.bbclass
+++ b/meta/classes/package_rpm.bbclass
@@ -443,6 +443,7 @@ export D="${target_rootfs}"
 export OFFLINE_ROOT="\$D"
 export IPKG_OFFLINE_ROOT="\$D"
 export OPKG_OFFLINE_ROOT="\$D"
+export NATIVE_DIR="${STAGING_DIR_NATIVE}"
 
 \$2 \$1/\$3 \$4
 if [ \$? -ne 0 ]; then
-- 
1.7.9.5

Re: [PATCH 3/5] package_rpm: export the native directory to the postinst scriptlets

[Mark Hatle]

On 8/3/12 3:19 PM, Laurentiu Palcu wrote:
> Some postinst scriptlets test for the existence of certain files but
> have the paths hardcoded to the target's rootfs. This patch will allow
> us to run postinst scriptlets at do_rootfs time by calling native
> binaries.
>
> Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
> ---
>   meta/classes/package_rpm.bbclass |    1 +
>   1 file changed, 1 insertion(+)
>
> diff --git a/meta/classes/package_rpm.bbclass b/meta/classes/package_rpm.bbclass
> index 50e9b31..113b19c 100644
> --- a/meta/classes/package_rpm.bbclass
> +++ b/meta/classes/package_rpm.bbclass
> @@ -443,6 +443,7 @@ export D="${target_rootfs}"
>   export OFFLINE_ROOT="\$D"
>   export IPKG_OFFLINE_ROOT="\$D"
>   export OPKG_OFFLINE_ROOT="\$D"
> +export NATIVE_DIR="${STAGING_DIR_NATIVE}"

Why is this needed?  Normally the host items run from the path (and should know 
how to access any related files they need), and ${D} points to the target rootfs 
directory for things needing full paths.

--Mark

>
>   \$2 \$1/\$3 \$4
>   if [ \$? -ne 0 ]; then
>

Re: [PATCH 3/5] package_rpm: export the native directory to the postinst scriptlets

[Laurentiu Palcu]

On 08/03/2012 11:25 PM, Mark Hatle wrote:
> On 8/3/12 3:19 PM, Laurentiu Palcu wrote:
>> Some postinst scriptlets test for the existence of certain files but
>> have the paths hardcoded to the target's rootfs. This patch will allow
>> us to run postinst scriptlets at do_rootfs time by calling native
>> binaries.
>>
>> Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
>> ---
>>   meta/classes/package_rpm.bbclass |    1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/meta/classes/package_rpm.bbclass b/meta/classes/package_rpm.bbclass
>> index 50e9b31..113b19c 100644
>> --- a/meta/classes/package_rpm.bbclass
>> +++ b/meta/classes/package_rpm.bbclass
>> @@ -443,6 +443,7 @@ export D="${target_rootfs}"
>>   export OFFLINE_ROOT="\$D"
>>   export IPKG_OFFLINE_ROOT="\$D"
>>   export OPKG_OFFLINE_ROOT="\$D"
>> +export NATIVE_DIR="${STAGING_DIR_NATIVE}"
> 
> Why is this needed?  Normally the host items run from the path (and should know 
> how to access any related files they need), and ${D} points to the target rootfs 
> directory for things needing full paths.
Hmm, I think you're perfectly right... I needed it because the
gdk-pixbuf postinst scriplet tested the existence of
gtk-update-icon-cache binary but, now that you mentioned it, I realized
it might work without it. Test the existence of the binary on target
rootfs but run the native one from PATH.

Thanks for the tip,
Laurentiu
> 
> --Mark
> 
>>
>>   \$2 \$1/\$3 \$4
>>   if [ \$? -ne 0 ]; then
>>
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> 

Re: [PATCH 3/5] package_rpm: export the native directory to the postinst scriptlets

[Laurentiu Palcu]

On 08/04/2012 10:46 AM, Laurentiu Palcu wrote:
> 
> 
> On 08/03/2012 11:25 PM, Mark Hatle wrote:
>> On 8/3/12 3:19 PM, Laurentiu Palcu wrote:
>>> Some postinst scriptlets test for the existence of certain files but
>>> have the paths hardcoded to the target's rootfs. This patch will allow
>>> us to run postinst scriptlets at do_rootfs time by calling native
>>> binaries.
>>>
>>> Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
>>> ---
>>>   meta/classes/package_rpm.bbclass |    1 +
>>>   1 file changed, 1 insertion(+)
>>>
>>> diff --git a/meta/classes/package_rpm.bbclass b/meta/classes/package_rpm.bbclass
>>> index 50e9b31..113b19c 100644
>>> --- a/meta/classes/package_rpm.bbclass
>>> +++ b/meta/classes/package_rpm.bbclass
>>> @@ -443,6 +443,7 @@ export D="${target_rootfs}"
>>>   export OFFLINE_ROOT="\$D"
>>>   export IPKG_OFFLINE_ROOT="\$D"
>>>   export OPKG_OFFLINE_ROOT="\$D"
>>> +export NATIVE_DIR="${STAGING_DIR_NATIVE}"
>>
>> Why is this needed?  Normally the host items run from the path (and should know 
>> how to access any related files they need), and ${D} points to the target rootfs 
>> directory for things needing full paths.
> Hmm, I think you're perfectly right... I needed it because the
> gdk-pixbuf postinst scriplet tested the existence of
> gtk-update-icon-cache binary but, now that you mentioned it, I realized
> it might work without it. Test the existence of the binary on target
> rootfs but run the native one from PATH.
However, I just remembered that the rpm packages are not installed in
dependency order... So, there might be packages, that need
gtk-update-icon-cache, installed before libgtk+ is installed. In this
case, the postinst scriptlets that test the existence of the binary on
the target rootfs will fail at do_roofts time... Unless a solution is
found to install the rpm packages in dependency order. BTW, is this
planned to be fixed?

Laurentiu
> 
> Thanks for the tip,
> Laurentiu
>>
>> --Mark
>>
>>>
>>>   \$2 \$1/\$3 \$4
>>>   if [ \$? -ne 0 ]; then
>>>
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> 

Re: [PATCH 3/5] package_rpm: export the native directory to the postinst scriptlets

[Mark Hatle]

On 8/4/12 3:59 AM, Laurentiu Palcu wrote:
>
>
> On 08/04/2012 10:46 AM, Laurentiu Palcu wrote:
>>
>>
>> On 08/03/2012 11:25 PM, Mark Hatle wrote:
>>> On 8/3/12 3:19 PM, Laurentiu Palcu wrote:
>>>> Some postinst scriptlets test for the existence of certain files but
>>>> have the paths hardcoded to the target's rootfs. This patch will allow
>>>> us to run postinst scriptlets at do_rootfs time by calling native
>>>> binaries.
>>>>
>>>> Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
>>>> ---
>>>>    meta/classes/package_rpm.bbclass |    1 +
>>>>    1 file changed, 1 insertion(+)
>>>>
>>>> diff --git a/meta/classes/package_rpm.bbclass b/meta/classes/package_rpm.bbclass
>>>> index 50e9b31..113b19c 100644
>>>> --- a/meta/classes/package_rpm.bbclass
>>>> +++ b/meta/classes/package_rpm.bbclass
>>>> @@ -443,6 +443,7 @@ export D="${target_rootfs}"
>>>>    export OFFLINE_ROOT="\$D"
>>>>    export IPKG_OFFLINE_ROOT="\$D"
>>>>    export OPKG_OFFLINE_ROOT="\$D"
>>>> +export NATIVE_DIR="${STAGING_DIR_NATIVE}"
>>>
>>> Why is this needed?  Normally the host items run from the path (and should know
>>> how to access any related files they need), and ${D} points to the target rootfs
>>> directory for things needing full paths.
>> Hmm, I think you're perfectly right... I needed it because the
>> gdk-pixbuf postinst scriplet tested the existence of
>> gtk-update-icon-cache binary but, now that you mentioned it, I realized
>> it might work without it. Test the existence of the binary on target
>> rootfs but run the native one from PATH.
> However, I just remembered that the rpm packages are not installed in
> dependency order... So, there might be packages, that need
> gtk-update-icon-cache, installed before libgtk+ is installed. In this
> case, the postinst scriptlets that test the existence of the binary on
> the target rootfs will fail at do_roofts time... Unless a solution is
> found to install the rpm packages in dependency order. BTW, is this
> planned to be fixed?

Install order vs scriptlet order are different.  The package dependencies 
indicate when the transaction is complete all dependent packages will be 
installed.  The scriptlets can be delayed or run during the install process. 
I'm not sure what controls when they run, but that is a separate action from the 
actual install process itself.

I have not has the time to investigate the control of the scriptlets, but it's 
on my list.

Back to the issue at hand though.  Two solutions, the first is simply run the 
program and if it fails, ignore the failure or "stage" it for later (or fail), 
whichever is appropriate.  The only thing that checking for the binary 
accomplishes is knowing if it might fail or not, it's likely just as easy to 
check for a failure trying to run the binary.

For the cross install case, you can check for the existence of the ${D} 
variable.  If it doesn't exist then you are on the target, and you can do 
whatever checks are necessary -- but on the host side you will have to assume 
the binary exists and is available [based on the recipe requirements.]

--Mark

> Laurentiu
>>
>> Thanks for the tip,
>> Laurentiu
>>>
>>> --Mark
>>>
>>>>
>>>>    \$2 \$1/\$3 \$4
>>>>    if [ \$? -ne 0 ]; then
>>>>
>>>
>>>
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>

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

[Laurentiu Palcu]

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

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

[Andreas Müller]

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/

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

[Laurentiu Palcu]

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
> 

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

[Andreas Müller]

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/
>>

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

[Laurentiu Palcu]

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
> 

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

[Koen Kooi]

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

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

[Andreas Müller]

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

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

[Khem Raj]

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.

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

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 1159 bytes --]

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.

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

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

[Andreas Müller]

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

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

[Laurentiu Palcu]

[-- Attachment #1: Type: text/plain, Size: 2014 bytes --]



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
> 

[-- Attachment #2: measure_time.patch --]
[-- Type: text/x-patch, Size: 961 bytes --]

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)
 

[-- Attachment #3: do_rootfs.log --]
[-- Type: text/x-log, Size: 3556 bytes --]

Executing: gtk-update-icon-cache -q /ssd/yocto/build/tmp/work/qemuarm-poky-linux-gnueabi/core-image-sato-1.0-r0/rootfs//usr/share/icons/hicolor
real:0.05 user:0.00 sys:0.03
Executing: gtk-update-icon-cache -q /ssd/yocto/build/tmp/work/qemuarm-poky-linux-gnueabi/core-image-sato-1.0-r0/rootfs//usr/share/icons/hicolor
real:0.00 user:0.00 sys:0.00
Executing: gtk-update-icon-cache -q /ssd/yocto/build/tmp/work/qemuarm-poky-linux-gnueabi/core-image-sato-1.0-r0/rootfs//usr/share/icons/hicolor
real:0.00 user:0.00 sys:0.00
Executing: gtk-update-icon-cache -q /ssd/yocto/build/tmp/work/qemuarm-poky-linux-gnueabi/core-image-sato-1.0-r0/rootfs//usr/share/icons/hicolor
real:0.00 user:0.00 sys:0.00
Executing: gtk-update-icon-cache -fqt /ssd/yocto/build/tmp/work/qemuarm-poky-linux-gnueabi/core-image-sato-1.0-r0/rootfs/usr/share/icons/Sato
real:0.25 user:0.01 sys:0.15
Executing: gtk-update-icon-cache -fqt /ssd/yocto/build/tmp/work/qemuarm-poky-linux-gnueabi/core-image-sato-1.0-r0/rootfs/usr/share/icons/hicolor
real:0.05 user:0.01 sys:0.01
Executing: gtk-update-icon-cache -fqt /ssd/yocto/build/tmp/work/qemuarm-poky-linux-gnueabi/core-image-sato-1.0-r0/rootfs/usr/share/icons/xcursor-transparent
real:0.00 user:0.00 sys:0.00
Executing: gtk-update-icon-cache -fqt /ssd/yocto/build/tmp/work/qemuarm-poky-linux-gnueabi/core-image-sato-1.0-r0/rootfs/usr/share/icons/Sato
real:0.25 user:0.04 sys:0.12
Executing: gtk-update-icon-cache -fqt /ssd/yocto/build/tmp/work/qemuarm-poky-linux-gnueabi/core-image-sato-1.0-r0/rootfs/usr/share/icons/hicolor
real:0.04 user:0.00 sys:0.02
Executing: gtk-update-icon-cache -fqt /ssd/yocto/build/tmp/work/qemuarm-poky-linux-gnueabi/core-image-sato-1.0-r0/rootfs/usr/share/icons/xcursor-transparent
real:0.00 user:0.00 sys:0.00
Executing: gtk-update-icon-cache -q /ssd/yocto/build/tmp/work/qemuarm-poky-linux-gnueabi/core-image-sato-1.0-r0/rootfs/usr/share/icons/Sato
real:0.00 user:0.00 sys:0.00
Executing: gtk-update-icon-cache -fqt /ssd/yocto/build/tmp/work/qemuarm-poky-linux-gnueabi/core-image-sato-1.0-r0/rootfs/usr/share/icons/Sato
real:0.25 user:0.03 sys:0.13
Executing: gtk-update-icon-cache -fqt /ssd/yocto/build/tmp/work/qemuarm-poky-linux-gnueabi/core-image-sato-1.0-r0/rootfs/usr/share/icons/hicolor
real:0.05 user:0.00 sys:0.03
Executing: gtk-update-icon-cache -fqt /ssd/yocto/build/tmp/work/qemuarm-poky-linux-gnueabi/core-image-sato-1.0-r0/rootfs/usr/share/icons/xcursor-transparent
real:0.00 user:0.00 sys:0.00
Executing: gtk-update-icon-cache -fqt /ssd/yocto/build/tmp/work/qemuarm-poky-linux-gnueabi/core-image-sato-1.0-r0/rootfs/usr/share/icons/Sato
real:0.25 user:0.03 sys:0.13
Executing: gtk-update-icon-cache -fqt /ssd/yocto/build/tmp/work/qemuarm-poky-linux-gnueabi/core-image-sato-1.0-r0/rootfs/usr/share/icons/hicolor
real:0.05 user:0.00 sys:0.03
Executing: gtk-update-icon-cache -fqt /ssd/yocto/build/tmp/work/qemuarm-poky-linux-gnueabi/core-image-sato-1.0-r0/rootfs/usr/share/icons/xcursor-transparent
real:0.00 user:0.00 sys:0.00
Executing: gtk-update-icon-cache -fqt /ssd/yocto/build/tmp/work/qemuarm-poky-linux-gnueabi/core-image-sato-1.0-r0/rootfs/usr/share/icons/Sato
real:0.26 user:0.04 sys:0.13
Executing: gtk-update-icon-cache -fqt /ssd/yocto/build/tmp/work/qemuarm-poky-linux-gnueabi/core-image-sato-1.0-r0/rootfs/usr/share/icons/hicolor
real:0.04 user:0.00 sys:0.02
Executing: gtk-update-icon-cache -fqt /ssd/yocto/build/tmp/work/qemuarm-poky-linux-gnueabi/core-image-sato-1.0-r0/rootfs/usr/share/icons/xcursor-transparent
real:0.00 user:0.00 sys:0.00

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

[Andreas Müller]

[-- Attachment #1: Type: text/plain, Size: 769 bytes --]

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

[-- Attachment #2: do_rootfs.log --]
[-- Type: text/x-log, Size: 11571 bytes --]

Executing: gtk-update-icon-cache -f -t /home/Superandy/tmp/oe-core-eglibc/work/armv7a-vfp-neon-angstrom-linux-gnueabi/gnome-bluetooth-2.32.0-r1/image/usr/share/icons/hicolor
real:0.32 user:0.00 sys:0.00
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/gnome
real:12.62 user:1.09 sys:6.96
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/hicolor
real:1.36 user:0.11 sys:0.71
Executing: gtk-update-icon-cache -q /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs//usr/share/icons/hicolor
real:0.02 user:0.00 sys:0.01
Executing: gtk-update-icon-cache -q /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs//usr/share/icons/hicolor
real:0.02 user:0.00 sys:0.01
Executing: gtk-update-icon-cache -q /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs//usr/share/icons/hicolor
real:0.02 user:0.00 sys:0.01
Executing: gtk-update-icon-cache -q /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs//usr/share/icons/hicolor
real:0.01 user:0.00 sys:0.01
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/gnome
real:10.57 user:0.98 sys:5.89
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/hicolor
real:1.31 user:0.09 sys:0.71
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/gnome
real:12.58 user:1.11 sys:7.08
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/hicolor
real:1.32 user:0.13 sys:0.68
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/gnome
real:12.06 user:1.14 sys:6.72
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/hicolor
real:1.21 user:0.11 sys:0.62
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/gnome
real:11.18 user:1.03 sys:6.26
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/hicolor
real:0.97 user:0.09 sys:0.50
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/gnome
real:11.51 user:1.06 sys:6.45
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/hicolor
real:0.92 user:0.09 sys:0.45
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/gnome
real:13.03 user:1.19 sys:7.31
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/hicolor
real:1.33 user:0.10 sys:0.71
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/gnome
real:13.08 user:1.15 sys:7.40
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/hicolor
real:1.35 user:0.14 sys:0.69
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/gnome
real:13.05 user:1.19 sys:7.35
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/hicolor
real:1.32 user:0.10 sys:0.70
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/gnome
real:12.95 user:1.09 sys:7.39
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/hicolor
real:1.31 user:0.11 sys:0.69
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/gnome
real:13.01 user:1.17 sys:7.30
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/hicolor
real:1.29 user:0.13 sys:0.68
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/gnome
real:12.96 user:1.18 sys:7.30
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/hicolor
real:1.33 user:0.11 sys:0.70
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/gnome
real:11.70 user:1.21 sys:6.30
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/hicolor
real:1.40 user:0.12 sys:0.64
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/gnome
real:13.00 user:1.14 sys:7.33
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/hicolor
real:1.25 user:0.12 sys:0.64
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/gnome
real:12.56 user:1.13 sys:7.06
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/hicolor
real:1.39 user:0.11 sys:0.70
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/gnome
real:13.21 user:1.21 sys:7.37
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/hicolor
real:1.30 user:0.11 sys:0.70
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/gnome
real:12.99 user:1.20 sys:7.27
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/hicolor
real:1.35 user:0.12 sys:0.70
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/gnome
real:13.08 user:1.19 sys:7.29
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/hicolor
real:1.31 user:0.11 sys:0.70
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/gnome
real:13.05 user:1.18 sys:7.30
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/hicolor
real:1.30 user:0.10 sys:0.69
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/gnome
real:12.76 user:1.16 sys:7.14
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/hicolor
real:1.38 user:0.11 sys:0.71
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/gnome
real:13.05 user:1.13 sys:7.40
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/hicolor
real:1.31 user:0.11 sys:0.70
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/gnome
real:12.90 user:1.08 sys:7.33
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/hicolor
real:1.31 user:0.13 sys:0.68
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/gnome
real:12.65 user:1.14 sys:7.11
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/hicolor
real:1.32 user:0.09 sys:0.72
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/gnome
real:13.16 user:1.15 sys:7.42
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/hicolor
real:1.32 user:0.10 sys:0.71
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/gnome
real:13.07 user:1.24 sys:7.22
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/hicolor
real:1.36 user:0.11 sys:0.71
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/gnome
real:12.65 user:1.16 sys:6.90
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/hicolor
real:1.20 user:0.10 sys:0.62
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/gnome
real:12.82 user:1.17 sys:7.15
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/hicolor
real:1.28 user:0.11 sys:0.69
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/gnome
real:12.56 user:1.10 sys:7.07
Executing: gtk-update-icon-cache -fqt /home/Superandy/tmp/oe-core-eglibc/work/overo-angstrom-linux-gnueabi/xfce-full-image-1.0-r0/rootfs/usr/share/icons/hicolor
real:1.31 user:0.11 sys:0.70

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

[Andreas Müller]

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

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

[Laurentiu Palcu]

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
> 

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

[Andreas Müller]

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

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

[Laurentiu Palcu]

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
> 

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

[Burton, Ross]

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

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

[Andreas Müller]

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

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

[Andreas Müller]

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

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

[Koen Kooi]

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. 

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

[Koen Kooi]

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.

[PATCH 5/5] gdk-pixbuf: allow postinst scriplet to be called at do_rootfs time

[Laurentiu Palcu]

Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
---
 meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.24.1.bb |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.24.1.bb b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.24.1.bb
index 8e13115..60d6161 100644
--- a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.24.1.bb
+++ b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.24.1.bb
@@ -56,12 +56,14 @@ FILES_${PN}-dbg += " \
 
 postinst_pixbufloader () {
 if [ "x$D" != "x" ]; then
-    exit 1
+    gtk_update_icon_cache_path=$NATIVE_DIR/${bindir_native}
+else
+    gtk_update_icon_cache_path=${bindir}
 fi
 
 GDK_PIXBUF_MODULEDIR=${libdir}/gdk-pixbuf-2.0/${LIBV}/loaders gdk-pixbuf-query-loaders --update-cache
 
-test -x ${bindir}/gtk-update-icon-cache && gtk-update-icon-cache  -q ${datadir}/icons/hicolor
+test -x $gtk_update_icon_cache_path/gtk-update-icon-cache && gtk-update-icon-cache  -q $D/${datadir}/icons/hicolor
 }
 
 PACKAGES_DYNAMIC += "gdk-pixbuf-loader-*"
-- 
1.7.9.5