Run postinst scriptlets at do_rootfs time

PATCH In review Laurentiu Palcu 7 participants 31 messages Aug 3, 2012 – Aug 6, 2012

lore

Share & tools

lore

Laurentiu Palcu

author

2012-08-03 20:31 UTC #0 lore raw

cover Run postinst scriptlets at do_rootfs time

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

Signature · 1 line

1.7.9.5

Laurentiu Palcu

author

2012-08-03 20:31 UTC #1 lore raw

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

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

Signed-off-by Laurentiu Palcu <[email protected]>

---
 meta/recipes-gnome/gtk+/gtk+_2.24.8.bb |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

meta/recipes-gnome/gtk+/gtk+_2.24.8.bb +4 -1

index 529f8e1..878eb87 100644
@@ -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)

Signature · 1 line

1.7.9.5

Laurentiu Palcu

author

2012-08-03 20:31 UTC #2 lore raw

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

In reply to Laurentiu Palcu

Signed-off-by Laurentiu Palcu <[email protected]>

---
 .../sato-icon-theme/sato-icon-theme.inc            |   10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

meta/recipes-sato/sato-icon-theme/sato-icon-theme.inc +5 -5

index 9fd1012..ba15514 100644
@@ -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
 }

Signature · 1 line

1.7.9.5

Burton, Ross

2012-08-06 09:41 UTC #3 lore raw

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

meta/recipes-sato/sato-icon-theme/sato-icon-theme.inc EXTRA_OECONF += "--with-iconmap=${STAGING_LIBDIR_NATIVE}/../libexec/icon-name-ma · line 25

Quoted 11 lines · Laurentiu Palcu

pkg_postinst_${PN} () {

meta/recipes-sato/sato-icon-theme/sato-icon-theme.inc +4 -4

-        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

Laurentiu Palcu

author

2012-08-03 20:31 UTC #4 lore raw

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

In reply to 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 <[email protected]>

---
 meta/classes/package_rpm.bbclass |    1 +
 1 file changed, 1 insertion(+)

meta/classes/package_rpm.bbclass +1 -0

index 50e9b31..113b19c 100644
@@ -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

Signature · 1 line

1.7.9.5

Mark Hatle

2012-08-03 20:37 UTC #5 lore raw

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

Quoted 15 lines · 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 <[email protected]>
---
  meta/classes/package_rpm.bbclass |    1 +
  1 file changed, 1 insertion(+)
meta/classes/package_rpm.bbclass +0 -0
index 50e9b31..113b19c 100644

meta/classes/package_rpm.bbclass export D="${target_rootfs}" · line 446

Quoted 4 lines

meta/classes/package_rpm.bbclass +1 -0

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

Quoted 4 lines

meta/classes/package_rpm.bbclass +0 -0
  \$2 \$1/\$3 \$4
  if [ \$? -ne 0 ]; then
 

Laurentiu Palcu

author

2012-08-04 07:58 UTC #6 lore raw

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

Quoted 11 lines · Mark Hatle

Quoted 10 lines · 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 <[email protected]>
---
  meta/classes/package_rpm.bbclass |    1 +
  1 file changed, 1 insertion(+)

Quoted 13 lines

meta/classes/package_rpm.bbclass export D="${target_rootfs}" · line 446
Quoted 9 lines
meta/classes/package_rpm.bbclass +1 -0
index 50e9b31..113b19c 100644
@@ -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

Quoted 14 lines

--Mark
meta/classes/package_rpm.bbclass export D="${target_rootfs}"
Quoted 4 lines
meta/classes/package_rpm.bbclass +0 -0
  \$2 \$1/\$3 \$4
  if [ \$? -ne 0 ]; then
 
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Laurentiu Palcu

author

2012-08-04 09:11 UTC #7 lore raw

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

Quoted 27 lines · Laurentiu Palcu

Quoted 11 lines · Mark Hatle
Quoted 10 lines · 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 <[email protected]>
---
  meta/classes/package_rpm.bbclass |    1 +
  1 file changed, 1 insertion(+)
Quoted 13 lines
meta/classes/package_rpm.bbclass export D="${target_rootfs}" · line 446
Quoted 9 lines
meta/classes/package_rpm.bbclass +1 -0
index 50e9b31..113b19c 100644
@@ -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.

Quoted 5 lines

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

Quoted 23 lines

Thanks for the tip,
Laurentiu
Quoted 9 lines
--Mark
meta/classes/package_rpm.bbclass export D="${target_rootfs}"
Quoted 4 lines
meta/classes/package_rpm.bbclass +0 -0
  \$2 \$1/\$3 \$4
  if [ \$? -ne 0 ]; then
 
Quoted 5 lines
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Mark Hatle

2012-08-04 14:53 UTC #8 lore raw

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

Quoted 35 lines · Laurentiu Palcu

Quoted 27 lines · Laurentiu Palcu
Quoted 11 lines · Mark Hatle
Quoted 10 lines · 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 <[email protected]>
---
   meta/classes/package_rpm.bbclass |    1 +
   1 file changed, 1 insertion(+)
Quoted 13 lines
meta/classes/package_rpm.bbclass export D="${target_rootfs}" · line 446
Quoted 9 lines
meta/classes/package_rpm.bbclass +1 -0
index 50e9b31..113b19c 100644
@@ -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.
Quoted 5 lines
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.

Quoted 7 lines

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

Quoted 30 lines

Laurentiu
Quoted 18 lines
Thanks for the tip,
Laurentiu
Quoted 9 lines
--Mark
meta/classes/package_rpm.bbclass export D="${target_rootfs}"
Quoted 4 lines
meta/classes/package_rpm.bbclass +0 -0
   \$2 \$1/\$3 \$4
   if [ \$? -ne 0 ]; then
 
Quoted 5 lines
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Quoted 5 lines
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Laurentiu Palcu

author

2012-08-03 20:31 UTC #9 lore raw

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

In reply to 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 <[email protected]>

---
 meta/classes/gtk-icon-cache.bbclass |   10 ++--------
 1 file changed, 2 insertions(+), 8 deletions(-)

meta/classes/gtk-icon-cache.bbclass +2 -8

index 01fb2f3..2d82c54 100644
@@ -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

Signature · 1 line

1.7.9.5

Andreas Müller

2012-08-03 23:34 UTC #10 lore raw

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

Quoted 34 lines · 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 <[email protected]>

---
 meta/classes/gtk-icon-cache.bbclass |   10 ++--------
 1 file changed, 2 insertions(+), 8 deletions(-)

meta/classes/gtk-icon-cache.bbclass +2 -9

index 01fb2f3..2d82c54 100644
@@ -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
--

Quoted 2 lines

1.7.9.5

Long time ago there was a patch introducing gtk-icon-cache to be only run once on the machine [1] and I am still using that. At that time I was asked for a more generic approach. Now I ask:

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

Andreas

[1] http://patches.openembedded.org/patch/24179/

Laurentiu Palcu

author

2012-08-04 08:00 UTC #11 lore raw

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

Quoted 42 lines · Andreas Müller

Quoted 34 lines · 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 <[email protected]>
---
 meta/classes/gtk-icon-cache.bbclass |   10 ++--------
 1 file changed, 2 insertions(+), 8 deletions(-)
meta/classes/gtk-icon-cache.bbclass +2 -9
index 01fb2f3..2d82c54 100644
@@ -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
--
Quoted 2 lines
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:

Quoted 1 line

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

Quoted 11 lines

2. Or better: How about a postinst 'runonce' framework for host/machine?
Andreas
[1] http://patches.openembedded.org/patch/24179/
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Andreas Müller

2012-08-04 09:41 UTC #12 lore raw

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

Quoted 45 lines · Laurentiu Palcu

Quoted 42 lines · Andreas Müller
Quoted 34 lines · 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 <[email protected]>
---
 meta/classes/gtk-icon-cache.bbclass |   10 ++--------
 1 file changed, 2 insertions(+), 8 deletions(-)
meta/classes/gtk-icon-cache.bbclass +2 -9
index 01fb2f3..2d82c54 100644
@@ -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
--
Quoted 2 lines
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:

Quoted 4 lines

Quoted 1 line
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

Quoted 10 lines

Thanks,
Laurentiu
Quoted 6 lines
2. Or better: How about a postinst 'runonce' framework for host/machine?
Andreas
[1] http://patches.openembedded.org/patch/24179/

Laurentiu Palcu

author

2012-08-04 14:12 UTC #13 lore raw

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

Quoted 47 lines · Andreas Müller

Quoted 45 lines · Laurentiu Palcu
Quoted 42 lines · Andreas Müller
Quoted 34 lines · 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 <[email protected]>
---
 meta/classes/gtk-icon-cache.bbclass |   10 ++--------
 1 file changed, 2 insertions(+), 8 deletions(-)
meta/classes/gtk-icon-cache.bbclass +2 -9
index 01fb2f3..2d82c54 100644
@@ -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
--
Quoted 2 lines
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:

Quoted 6 lines

Quoted 4 lines
Quoted 1 line
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

Quoted 18 lines

Andreas
Quoted 10 lines
Thanks,
Laurentiu
Quoted 6 lines
2. Or better: How about a postinst 'runonce' framework for host/machine?
Andreas
[1] http://patches.openembedded.org/patch/24179/
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Koen Kooi

2012-08-04 17:25 UTC #14 lore raw

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

Op 4 aug. 2012, om 16:01 heeft Laurentiu Palcu <[email protected]> het volgende geschreven:

Quoted 54 lines · Andreas Müller

Quoted 51 lines
Quoted 49 lines · Laurentiu Palcu
Quoted 42 lines · Andreas Müller
Quoted 34 lines · 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 <[email protected]>
---
meta/classes/gtk-icon-cache.bbclass | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
meta/classes/gtk-icon-cache.bbclass +0 -0
index 01fb2f3..2d82c54 100644
@@ -1,18 +1,12 @@
FILES_${PN} += "${datadir}/icons/hicolor"
meta/classes/gtk-icon-cache.bbclass +1 -3
-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() {
meta/classes/gtk-icon-cache.bbclass +0 -4
-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
meta/classes/gtk-icon-cache.bbclass +1 -2
-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
--
Quoted 2 lines
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:
Quoted 1 line
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.

Quoted 8 lines

Quoted 2 lines
As far as I can see gtk-icon-cache is run for each package - how much extra build time at do_rootfs is to expect?
I didn't measure it. But I didn't notice do_roofts task taking a lot more than it took previously. However, host machines these days have lots of MHz under the hood, multiple cores and quite a lot of RAM, compared to target machines. So, I do believe that waiting for some extra tens of seconds at build time is a trade-off we can live with, compared to waiting entire minutes for the target's first boot.

it's about 90 minutes on first boot for beaglebone :)

Andreas Müller

2012-08-04 19:48 UTC #15 lore raw

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

Quoted 59 lines · Koen Kooi

Op 4 aug. 2012, om 16:01 heeft Laurentiu Palcu <[email protected]> het volgende geschreven:
Quoted 56 lines · Andreas Müller
Quoted 53 lines
Quoted 45 lines · Laurentiu Palcu
Quoted 42 lines · Andreas Müller
Quoted 34 lines · 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 <[email protected]>
---
meta/classes/gtk-icon-cache.bbclass | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
meta/classes/gtk-icon-cache.bbclass +0 -0
index 01fb2f3..2d82c54 100644
@@ -1,18 +1,12 @@
FILES_${PN} += "${datadir}/icons/hicolor"
meta/classes/gtk-icon-cache.bbclass +1 -3
-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() {
meta/classes/gtk-icon-cache.bbclass +0 -4
-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
meta/classes/gtk-icon-cache.bbclass +1 -2
-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
--
Quoted 2 lines
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:
Quoted 4 lines
Quoted 1 line
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?

Quoted 8 lines

Quoted 6 lines
I didn't measure it. But I didn't notice do_roofts task taking a lot more than it took previously. However, host machines these days have lots of MHz under the hood, multiple cores and quite a lot of RAM, compared to target machines. So, I do believe that waiting for some extra tens of seconds at build time is a trade-off we can live with, compared to waiting entire minutes for the target's first boot.
it's about 90 minutes on first boot for beaglebone :)

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

Andreas

Khem Raj

2012-08-04 20:04 UTC #16 lore raw

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

Quoted 7 lines · Andreas Müller

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

I certainly agree with you that it should be run once. However what if you changed something in icons between towo do rootfs runs ? but I would like to know how much build time is it adding to do_rootfs ? sometimes over optimising is bad too.

Martin Jansa

2012-08-04 20:08 UTC #17 lore raw

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

Quoted 10 lines · Khem Raj

Quoted 7 lines · Andreas Müller
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...

Quoted 4 lines

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.

Signature · 1 line

Martin 'JaMa' Jansa     jabber: [email protected]

Andreas Müller

2012-08-04 20:37 UTC #18 lore raw

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

Quoted 11 lines · Martin Jansa

Quoted 10 lines · Khem Raj
Quoted 7 lines · Andreas Müller
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...

Quoted 4 lines

Quoted 4 lines
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...

Quoted 5 lines

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

Laurentiu Palcu

author

2012-08-05 17:10 UTC #19 lore raw

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

In reply to Khem Raj

Quoted 10 lines · Khem Raj

Quoted 7 lines · Andreas Müller
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...

Quoted 3 lines

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

Quoted 7 lines

sometimes over optimising is bad too.
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

meta/recipes-gnome/gtk+/gtk+_2.24.8.bb +12 -0

index 878eb87..e77ecce 100644
@@ -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)

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

Andreas Müller

2012-08-05 22:41 UTC #20 lore raw

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

Quoted 4 lines · Laurentiu Palcu

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

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

Andreas Müller

2012-08-05 23:00 UTC #21 lore raw

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

Quoted 12 lines · Andreas Müller

Quoted 4 lines · Laurentiu Palcu
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...

Quoted 3 lines

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

author

2012-08-06 08:00 UTC #22 lore raw

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

Quoted 8 lines · Andreas Müller

Quoted 6 lines · Andreas Müller
Quoted 4 lines · Laurentiu Palcu
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.

Quoted 5 lines

Quoted 5 lines
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.

Quoted 6 lines

Quoted 4 lines
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.

Quoted 7 lines

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.

Quoted 8 lines

Andreas
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Andreas Müller

2012-08-06 08:21 UTC #23 lore raw

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

Quoted 24 lines · Laurentiu Palcu

Quoted 8 lines · Andreas Müller
Quoted 6 lines · Andreas Müller
Quoted 4 lines · Laurentiu Palcu
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.
Quoted 5 lines
Quoted 5 lines
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.
Quoted 1 line
Quoted 1 line

Quoted 6 lines

Quoted 5 lines
Quoted 3 lines
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.

Quoted 4 lines

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.
Quoted 1 line

Quoted 8 lines

Quoted 6 lines
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

author

2012-08-06 09:30 UTC #24 lore raw

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

Quoted 26 lines · Andreas Müller

Quoted 24 lines · Laurentiu Palcu
Quoted 8 lines · Andreas Müller
Quoted 6 lines · Andreas Müller
Quoted 4 lines · Laurentiu Palcu
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.
Quoted 5 lines
Quoted 5 lines
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.
Quoted 1 line
Quoted 1 line

Quoted 7 lines

Quoted 6 lines
Quoted 5 lines
Quoted 3 lines
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.

Quoted 8 lines

Quoted 8 lines
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.
Quoted 5 lines
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

Quoted 6 lines

Quoted 4 lines
Quoted 2 lines
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

Quoted 8 lines

Andreas
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Burton, Ross

2012-08-06 09:47 UTC #25 lore raw

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

Quoted 5 lines · Laurentiu Palcu

Quoted 2 lines
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

2012-08-06 09:48 UTC #26 lore raw

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

In reply to Laurentiu Palcu

Quoted 54 lines · Laurentiu Palcu

Quoted 26 lines · Andreas Müller
Quoted 24 lines · Laurentiu Palcu
Quoted 8 lines · Andreas Müller
Quoted 6 lines · Andreas Müller
Quoted 4 lines · Laurentiu Palcu
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.
Quoted 5 lines
Quoted 5 lines
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.
Quoted 1 line
Quoted 1 line
Quoted 7 lines
Quoted 6 lines
Quoted 5 lines
Quoted 3 lines
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.
Quoted 8 lines
Quoted 8 lines
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.
Quoted 5 lines
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
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines
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.

Quoted 9 lines

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

2012-08-06 19:02 UTC #27 lore raw

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

In reply to Laurentiu Palcu

Quoted 63 lines · Laurentiu Palcu

Quoted 26 lines · Andreas Müller
Quoted 24 lines · Laurentiu Palcu
Quoted 8 lines · Andreas Müller
Quoted 6 lines · Andreas Müller
Quoted 4 lines · Laurentiu Palcu
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.
Quoted 5 lines
Quoted 5 lines
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.
Quoted 1 line
Quoted 1 line
Quoted 7 lines
Quoted 6 lines
Quoted 5 lines
Quoted 3 lines
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.
Quoted 8 lines
Quoted 8 lines
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.
Quoted 5 lines
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
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines
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...

Quoted 3 lines

Thanks,
Laurentiu

I checked: In both I find the files icon-theme.cache.

Andreas

Koen Kooi

2012-08-05 12:02 UTC #28 lore raw

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

In reply to Andreas Müller

Op 4 aug. 2012, om 21:37 heeft Andreas Müller <[email protected]> het volgende geschreven:

Quoted 69 lines · Koen Kooi

Quoted 59 lines
Op 4 aug. 2012, om 16:01 heeft Laurentiu Palcu <[email protected]> het volgende geschreven:
Quoted 56 lines · Andreas Müller
Quoted 53 lines
Quoted 45 lines · Laurentiu Palcu
Quoted 42 lines · Andreas Müller
Quoted 34 lines · 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 <[email protected]>
---
meta/classes/gtk-icon-cache.bbclass | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
meta/classes/gtk-icon-cache.bbclass +0 -0
index 01fb2f3..2d82c54 100644
@@ -1,18 +1,12 @@
FILES_${PN} += "${datadir}/icons/hicolor"
meta/classes/gtk-icon-cache.bbclass +1 -3
-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() {
meta/classes/gtk-icon-cache.bbclass +0 -4
-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
meta/classes/gtk-icon-cache.bbclass +1 -2
-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
--
Quoted 2 lines
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:
Quoted 4 lines
Quoted 1 line
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?
Quoted 8 lines
Quoted 6 lines
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 :)

Quoted 7 lines

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.

Koen Kooi

2012-08-04 10:36 UTC #29 lore raw

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

In reply to Laurentiu Palcu

Op 3 aug. 2012, om 22:19 heeft Laurentiu Palcu <[email protected]> het volgende geschreven:

Quoted 4 lines

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 <[email protected]>

Don't forget to send a patch with PR bumps for all recipes inheriting this class.

Laurentiu Palcu

author

2012-08-03 20:31 UTC #30 lore raw

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

In reply to Laurentiu Palcu

Signed-off-by Laurentiu Palcu <[email protected]>

---
 meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.24.1.bb |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.24.1.bb +4 -2

index 8e13115..60d6161 100644
@@ -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-*"

Signature · 1 line

1.7.9.5