[RFC 0/7] Postinstall improvements

[RFC 0/7] Postinstall improvements

[Laurentiu Palcu]

Hi,

It's been quite a long time since I sent the first version of postinstall
improvements which, after some debate, we decided it needed run-once
support of postinst scriptlets on host. This patcheset (RFC actually) adds
that.

So, in order to achieve this goal I took advantage of
ROOTFS_POSTPROCESS_COMMAND variable. Basically, if running some postinst
scriptlets is time consuming (even on host) and execute repeatedly,
then we can postpone the running and run the scriplet just once. The idea is
to put the scriptlet in the ${WORKDIR}/intercept_scripts directory. When the
ROOTFS_POSTPROCESS_COMMAND is executed, it will pick up all the scripts in
this directory and execute them.

This actual patchset does the above for the gtk icon cache generation which
takes a very long time to run on target and even on some hosts.

The people willing to give this patchset a test, are most than welcome. Also,
please feel free to review.

Thanks,
Laurentiu

The following changes since commit 913944d904266bf90af0cad94b4f0fb3652bd29d:

  upstream_tracking: update lsb and ltp (2012-09-14 17:12:52 +0100)

are available in the git repository at:

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

Laurentiu Palcu (7):
  gtk+: enable gtk+-native
  image.bbclass: run postinst scripts once, at rootfs time
  rootfs generation: export two new variables to postinst scriptlets
  gtk-icon-cache: run the icon generation at rootfs time
  gdk-pixbuf: generate the pixbuf loader's cache ar rootfs time
  sato-icon-theme: make use of the gtk-icon-cache postinst scriptlet
  postinst changes: bump PR to all recipes inheriting gnome and
    gtk-icon-cache

 meta/classes/gtk-icon-cache.bbclass                |   21 +++++++++++++----
 meta/classes/image.bbclass                         |   24 +++++++++++++++++++-
 meta/classes/package_rpm.bbclass                   |    2 ++
 meta/classes/rootfs_deb.bbclass                    |    2 ++
 meta/classes/rootfs_ipk.bbclass                    |    2 ++
 .../connman/connman-gnome_0.7.bb                   |    2 ++
 meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.24.1.bb |   24 ++++++++++++--------
 meta/recipes-gnome/gnome/gnome-common_2.28.0.bb    |    2 +-
 meta/recipes-gnome/gnome/gnome-desktop.inc         |    2 +-
 meta/recipes-gnome/gnome/gnome-doc-utils_0.20.6.bb |    2 +-
 meta/recipes-gnome/gnome/gnome-keyring_2.32.1.bb   |    2 +-
 meta/recipes-gnome/gnome/gnome-mime-data_2.18.0.bb |    2 +-
 meta/recipes-gnome/gnome/libgdata_0.7.1.bb         |    2 ++
 .../recipes-gnome/gnome/libgnome-keyring_2.32.0.bb |    2 +-
 meta/recipes-gnome/gnome/metacity_2.30.3.bb        |    2 +-
 meta/recipes-gnome/gthumb/gthumb_2.12.4.bb         |    2 +-
 meta/recipes-gnome/gtk+/gtk+_2.24.8.bb             |    5 +++-
 .../gtk-engines/gtk-engines_2.20.2.bb              |    2 +-
 .../hicolor-icon-theme/hicolor-icon-theme_0.12.bb  |    2 +-
 meta/recipes-gnome/json-glib/json-glib_0.14.2.bb   |    2 +-
 meta/recipes-gnome/libglade/libglade_2.6.4.bb      |    2 +-
 meta/recipes-gnome/librsvg/librsvg_2.32.1.bb       |    2 +-
 meta/recipes-graphics/mutter/mutter_2.29.1.bb      |    2 +-
 meta/recipes-graphics/mutter/mutter_git.bb         |    2 +-
 .../sato-icon-theme/sato-icon-theme.inc            |   13 ++++++-----
 .../sato-icon-theme/sato-icon-theme_0.4.1.bb       |    2 +-
 .../recipes-support/consolekit/consolekit_0.4.5.bb |    2 +-
 meta/recipes-support/libcroco/libcroco_0.6.3.bb    |    2 +-
 meta/recipes-support/vte/vte_0.28.2.bb             |    2 +-
 29 files changed, 94 insertions(+), 41 deletions(-)

-- 
1.7.9.5

[RFC 1/7] 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

[RFC 2/7] image.bbclass: run postinst scripts once, at rootfs time

[Laurentiu Palcu]

This patch will allow the repeating postinst scriptlets to be run
only once, on host, at do_rootfs time. This will lower the time for
rootfs generation and, also, instead of running some time consuming
scriptlets at target's first boot, we will do on the host.

Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
---
 meta/classes/image.bbclass |   24 +++++++++++++++++++++++-
 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index ab212b3..4889260 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -155,7 +155,7 @@ inherit ${IMAGE_CLASSES}
 
 IMAGE_POSTPROCESS_COMMAND ?= ""
 MACHINE_POSTPROCESS_COMMAND ?= ""
-ROOTFS_POSTPROCESS_COMMAND ?= ""
+ROOTFS_POSTPROCESS_COMMAND ?= "run_intercept_scriptlets"
 
 # some default locales
 IMAGE_LINGUAS ?= "de-de fr-fr en-gb"
@@ -174,6 +174,21 @@ do_build[nostamp] = "1"
 # task, so that we have a single fakeroot context for the whole process.
 do_rootfs[umask] = "022"
 
+
+run_intercept_scriptlets () {
+	echo $D >> test.txt
+	if [ -d ${WORKDIR}/intercept_scripts ]; then
+		cd ${WORKDIR}/intercept_scripts
+		echo "Running intercept scripts:"
+		for script in *; do
+			if [ "$script" = "*" ]; then break; fi
+			echo "> Executing $script"
+			chmod +x $script
+			./$script
+		done
+	fi
+}
+
 fakeroot do_rootfs () {
 	#set -x
 	# When use the rpm incremental image generation, don't remove the rootfs
@@ -202,6 +217,13 @@ fakeroot do_rootfs () {
 		done
 	fi
 
+	if [ -d ${WORKDIR}/intercept_scripts ]; then
+		# clean-up old intercept scripts
+		rm -f ${WORKDIR}/intercept_scripts/*
+	else
+		mkdir ${WORKDIR}/intercept_scripts
+	fi
+
 	rootfs_${IMAGE_PKGTYPE}_do_rootfs
 
 	insert_feed_uris
-- 
1.7.9.5

Re: [RFC 2/7] image.bbclass: run postinst scripts once, at rootfs time

[Burton, Ross]

On 19 September 2012 12:49, Laurentiu Palcu <laurentiu.palcu@intel.com> wrote:
> +ROOTFS_POSTPROCESS_COMMAND ?= "run_intercept_scriptlets"

From other examples, it looks like this should be "run_intercept_scriptlets;"

Also whilst this is a great proof of concept, maybe it should be
integrated into image.bblcass directly instead of being a postprocess
hook?  A postprocess hook might expect the postinstall scripts to have
been ran already, which they would have been if they were not
intercepted.

Ross

Re: [RFC 2/7] image.bbclass: run postinst scripts once, at rootfs time

[Laurentiu Palcu]

On 09/19/2012 06:14 PM, Burton, Ross wrote:
> On 19 September 2012 12:49, Laurentiu Palcu <laurentiu.palcu@intel.com> wrote:
>> +ROOTFS_POSTPROCESS_COMMAND ?= "run_intercept_scriptlets"
> 
> From other examples, it looks like this should be "run_intercept_scriptlets;"
Will do. My bad.

> 
> Also whilst this is a great proof of concept, maybe it should be
> integrated into image.bblcass directly instead of being a postprocess
> hook?  A postprocess hook might expect the postinstall scripts to have
> been ran already, which they would have been if they were not
> intercepted.
I'm a little confused here... Technically, when the postprocess hooks
are executed all the postinstall scripts were already executed. Ideally,
the run-once scripts are created from inside the postinst scriptlets
themselves. So, I don't really understand why using the postprocess hook
isn't safe. Can you please elaborate?

Thanks,
Laurentiu
> 
> Ross
> 

Re: [RFC 2/7] image.bbclass: run postinst scripts once, at rootfs time

[Burton, Ross]

On 19 September 2012 16:45, Laurentiu Palcu <laurentiu.palcu@intel.com> wrote:
> I'm a little confused here... Technically, when the postprocess hooks
> are executed all the postinstall scripts were already executed. Ideally,
> the run-once scripts are created from inside the postinst scriptlets
> themselves. So, I don't really understand why using the postprocess hook
> isn't safe. Can you please elaborate?

My concern (and it's just a hunch) is that there could be a
post-process hook running before the intercepts are run which could be
expecting the post install phase to have been completed.  With
intercepts a portion of the post-install phase is happening later than
they previously did, so they haven't completely been ran yet.

Ross

Re: [RFC 2/7] image.bbclass: run postinst scripts once, at rootfs time

[Laurentiu Palcu]

On 09/19/2012 06:50 PM, Burton, Ross wrote:
> On 19 September 2012 16:45, Laurentiu Palcu <laurentiu.palcu@intel.com> wrote:
>> I'm a little confused here... Technically, when the postprocess hooks
>> are executed all the postinstall scripts were already executed. Ideally,
>> the run-once scripts are created from inside the postinst scriptlets
>> themselves. So, I don't really understand why using the postprocess hook
>> isn't safe. Can you please elaborate?
> 
> My concern (and it's just a hunch) is that there could be a
> post-process hook running before the intercepts are run which could be
> expecting the post install phase to have been completed.  With
> intercepts a portion of the post-install phase is happening later than
> they previously did, so they haven't completely been ran yet.
I see your point now... The only place we could do it in image.bbclass
is immediately after rootfs_${IMAGE_PKGTYPE}_do_rootfs in do_rootfs()
function. But then we fall into the same issue you mentioned. The
post-process hooks would be executed before the intercept scripts...

The alternative would be to use the post-install hooks
(ROOTFS_POSTINSTALL_COMMAND) instead of post-process. These are executed
before the post-process hooks.

Thanks,
Laurentiu

> 
> Ross
> 

Re: [RFC 2/7] image.bbclass: run postinst scripts once, at rootfs time

[Richard Purdie]

On Wed, 2012-09-19 at 14:49 +0300, Laurentiu Palcu wrote:
> This patch will allow the repeating postinst scriptlets to be run
> only once, on host, at do_rootfs time. This will lower the time for
> rootfs generation and, also, instead of running some time consuming
> scriptlets at target's first boot, we will do on the host.
> 
> Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
> ---
>  meta/classes/image.bbclass |   24 +++++++++++++++++++++++-
>  1 file changed, 23 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
> index ab212b3..4889260 100644
> --- a/meta/classes/image.bbclass
> +++ b/meta/classes/image.bbclass
> @@ -155,7 +155,7 @@ inherit ${IMAGE_CLASSES}
>  
>  IMAGE_POSTPROCESS_COMMAND ?= ""
>  MACHINE_POSTPROCESS_COMMAND ?= ""
> -ROOTFS_POSTPROCESS_COMMAND ?= ""
> +ROOTFS_POSTPROCESS_COMMAND ?= "run_intercept_scriptlets"
>  
>  # some default locales
>  IMAGE_LINGUAS ?= "de-de fr-fr en-gb"
> @@ -174,6 +174,21 @@ do_build[nostamp] = "1"
>  # task, so that we have a single fakeroot context for the whole process.
>  do_rootfs[umask] = "022"
>  
> +
> +run_intercept_scriptlets () {
> +	echo $D >> test.txt
> +	if [ -d ${WORKDIR}/intercept_scripts ]; then
> +		cd ${WORKDIR}/intercept_scripts
> +		echo "Running intercept scripts:"
> +		for script in *; do
> +			if [ "$script" = "*" ]; then break; fi
> +			echo "> Executing $script"
> +			chmod +x $script
> +			./$script
> +		done
> +	fi
> +}
> +
>  fakeroot do_rootfs () {
>  	#set -x
>  	# When use the rpm incremental image generation, don't remove the rootfs
> @@ -202,6 +217,13 @@ fakeroot do_rootfs () {
>  		done
>  	fi
>  
> +	if [ -d ${WORKDIR}/intercept_scripts ]; then
> +		# clean-up old intercept scripts
> +		rm -f ${WORKDIR}/intercept_scripts/*
> +	else
> +		mkdir ${WORKDIR}/intercept_scripts
> +	fi

You can achieve this piece with:

do_rootfs[cleandirs] += "${WORKDIR}/intercept_scripts"

Cheers,

Richard

[RFC 3/7] rootfs generation: export two new variables to postinst scriptlets

[Laurentiu Palcu]

In order for the postinst scriptlets to be able to run once we need to
export the location of the intercept scripts and also the location of
native sysrootfs. The gdk-pixbuf binaries will need the latter because
in order to generate the loaders.cache it will need to scan some shared
libraries that must be native. Even though the output is a text file.

Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
---
 meta/classes/package_rpm.bbclass |    2 ++
 meta/classes/rootfs_deb.bbclass  |    2 ++
 meta/classes/rootfs_ipk.bbclass  |    2 ++
 3 files changed, 6 insertions(+)

diff --git a/meta/classes/package_rpm.bbclass b/meta/classes/package_rpm.bbclass
index 61f0117..8122243 100644
--- a/meta/classes/package_rpm.bbclass
+++ b/meta/classes/package_rpm.bbclass
@@ -468,6 +468,8 @@ export D="${target_rootfs}"
 export OFFLINE_ROOT="\$D"
 export IPKG_OFFLINE_ROOT="\$D"
 export OPKG_OFFLINE_ROOT="\$D"
+export INTERCEPT_DIR="${WORKDIR}/intercept_scripts"
+export NATIVE_ROOT=${STAGING_DIR_NATIVE}
 
 \$2 \$1/\$3 \$4
 if [ \$? -ne 0 ]; then
diff --git a/meta/classes/rootfs_deb.bbclass b/meta/classes/rootfs_deb.bbclass
index 881fdbd..955382f 100644
--- a/meta/classes/rootfs_deb.bbclass
+++ b/meta/classes/rootfs_deb.bbclass
@@ -48,6 +48,8 @@ fakeroot rootfs_deb_do_rootfs () {
 	export OFFLINE_ROOT=${IMAGE_ROOTFS}
 	export IPKG_OFFLINE_ROOT=${IMAGE_ROOTFS}
 	export OPKG_OFFLINE_ROOT=${IMAGE_ROOTFS}
+	export INTERCEPT_DIR=${WORKDIR}/intercept_scripts
+	export NATIVE_ROOT=${STAGING_DIR_NATIVE}
 
 	# Attempt to run preinsts
 	# Mark packages with preinst failures as unpacked
diff --git a/meta/classes/rootfs_ipk.bbclass b/meta/classes/rootfs_ipk.bbclass
index 6cdd8f6..3b1b120 100644
--- a/meta/classes/rootfs_ipk.bbclass
+++ b/meta/classes/rootfs_ipk.bbclass
@@ -69,6 +69,8 @@ fakeroot rootfs_ipk_do_rootfs () {
 	export OFFLINE_ROOT=${IMAGE_ROOTFS}
 	export IPKG_OFFLINE_ROOT=${IMAGE_ROOTFS}
 	export OPKG_OFFLINE_ROOT=${IPKG_OFFLINE_ROOT}
+	export INTERCEPT_DIR=${WORKDIR}/intercept_scripts
+	export NATIVE_ROOT=${STAGING_DIR_NATIVE}
 
 	package_install_internal_ipk
 
-- 
1.7.9.5

[RFC 4/7] gtk-icon-cache: run the icon generation at rootfs time

[Laurentiu Palcu]

This change will allow for the icon cache generation at rootfs time and
only once, at the end. So, even though there will be many packages
depending on gtk+, the icon cache generation will be done once.
Hopefully, this will lower the target's first boot time significantly
by using the power of the host machine to generate the cache.

Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
---
 meta/classes/gtk-icon-cache.bbclass |   21 +++++++++++++++++----
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/meta/classes/gtk-icon-cache.bbclass b/meta/classes/gtk-icon-cache.bbclass
index 01fb2f3..f65b11c 100644
--- a/meta/classes/gtk-icon-cache.bbclass
+++ b/meta/classes/gtk-icon-cache.bbclass
@@ -1,12 +1,24 @@
 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
+    if [ ! -f $INTERCEPT_DIR/update_icon_cache ]; then
+        cat << "EOF" > $INTERCEPT_DIR/update_icon_cache
+#!/bin/bash -x
+
+# Update the native pixbuf loader's cache
+gdk-pixbuf-query-loaders --update-cache
+
+for icondir in $D/usr/share/icons/* ; do
+    if [ -d $icondir ] ; then
+        gtk-update-icon-cache -fqt  $icondir
+    fi
+done
+EOF
+    fi
+    exit 0
 fi
 
 # Update the pixbuf loaders in case they haven't been registered yet
@@ -17,6 +29,7 @@ for icondir in /usr/share/icons/* ; do
         gtk-update-icon-cache -fqt  $icondir
     fi
 done
+
 }
 
 gtk_icon_cache_postrm() {
-- 
1.7.9.5

Re: [RFC 4/7] gtk-icon-cache: run the icon generation at rootfs time

[Khem Raj]

On Wed, Sep 19, 2012 at 4:49 AM, Laurentiu Palcu
<laurentiu.palcu@intel.com> wrote:
> This change will allow for the icon cache generation at rootfs time and
> only once, at the end. So, even though there will be many packages
> depending on gtk+, the icon cache generation will be done once.
> Hopefully, this will lower the target's first boot time significantly
> by using the power of the host machine to generate the cache.
>
> Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
> ---
>  meta/classes/gtk-icon-cache.bbclass |   21 +++++++++++++++++----
>  1 file changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/meta/classes/gtk-icon-cache.bbclass b/meta/classes/gtk-icon-cache.bbclass
> index 01fb2f3..f65b11c 100644
> --- a/meta/classes/gtk-icon-cache.bbclass
> +++ b/meta/classes/gtk-icon-cache.bbclass
> @@ -1,12 +1,24 @@
>  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
> +    if [ ! -f $INTERCEPT_DIR/update_icon_cache ]; then
> +        cat << "EOF" > $INTERCEPT_DIR/update_icon_cache
> +#!/bin/bash -x

Do you really need bash for this script to run ? if so then can it be
written so that it works on posixly shells.

> +
> +# Update the native pixbuf loader's cache
> +gdk-pixbuf-query-loaders --update-cache
> +
> +for icondir in $D/usr/share/icons/* ; do
> +    if [ -d $icondir ] ; then
> +        gtk-update-icon-cache -fqt  $icondir
> +    fi
> +done
> +EOF
> +    fi
> +    exit 0
>  fi
>
>  # Update the pixbuf loaders in case they haven't been registered yet
> @@ -17,6 +29,7 @@ for icondir in /usr/share/icons/* ; do
>          gtk-update-icon-cache -fqt  $icondir
>      fi
>  done
> +
>  }
>
>  gtk_icon_cache_postrm() {
> --
> 1.7.9.5
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [RFC 4/7] gtk-icon-cache: run the icon generation at rootfs time

[Burton, Ross]

On 19 September 2012 14:28, Khem Raj <raj.khem@gmail.com> wrote:
> Do you really need bash for this script to run ? if so then can it be
> written so that it works on posixly shells.

#! /bin/bash and no dependency on bash...  probably should make that
sh-compliant.

Ross

Re: [RFC 4/7] gtk-icon-cache: run the icon generation at rootfs time

[Laurentiu Palcu]

On 09/19/2012 04:38 PM, Burton, Ross wrote:
> On 19 September 2012 14:28, Khem Raj <raj.khem@gmail.com> wrote:
>> Do you really need bash for this script to run ? if so then can it be
>> written so that it works on posixly shells.
> 
> #! /bin/bash and no dependency on bash...  probably should make that
> sh-compliant.
Will do.

Thanks,
Laurentiu
> 
> Ross
> 

[RFC 5/7] gdk-pixbuf: generate the pixbuf loader's cache ar rootfs time

[Laurentiu Palcu]

This will generate the loaders.cache file for pixbuf, at rootfs time.

Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
---
 meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.24.1.bb |   24 ++++++++++++--------
 1 file changed, 14 insertions(+), 10 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 99f6cb4..c4afb97 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
@@ -57,18 +57,22 @@ FILES_${PN}-dbg += " \
 
 postinst_pixbufloader () {
 if [ "x$D" != "x" ]; then
-    exit 1
+# Update the target's pixbuf loader's cache. Since the native binary will
+# throw an error if the shared objects do not belong to the same ELF class,
+# we trick the gdk-pixbuf-query-loaders into scanning the native shared
+# objects and then we remove the NATIVE_ROOT prefix from the paths in
+# loaders.cache.
+gdk-pixbuf-query-loaders $(find $D/${libdir}/gdk-pixbuf-2.0/2.10.0/loaders \
+        -name *.so | sed -e "s:$D:$NATIVE_ROOT:g") > \
+        $D/${libdir}/gdk-pixbuf-2.0/2.10.0/loaders.cache || exit 1
+
+sed -i -e "s:$NATIVE_ROOT:/:g" $D/${libdir}/gdk-pixbuf-2.0/2.10.0/loaders.cache
+
+exit 0
 fi
 
-GDK_PIXBUF_MODULEDIR=${libdir}/gdk-pixbuf-2.0/${LIBV}/loaders gdk-pixbuf-query-loaders --update-cache
-
-if [ -x ${bindir}/gtk-update-icon-cache ] && [ -d ${datadir}/icons ]; then
-    for icondir in /usr/share/icons/*; do
-        if [ -d ${icondir} ]; then
-            gtk-update-icon-cache -t -q ${icondir}
-        fi
-    done
-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
 }
 
 PACKAGES_DYNAMIC += "gdk-pixbuf-loader-*"
-- 
1.7.9.5

Re: [RFC 5/7] gdk-pixbuf: generate the pixbuf loader's cache ar rootfs time

[Khem Raj]

On Wed, Sep 19, 2012 at 4:49 AM, Laurentiu Palcu
<laurentiu.palcu@intel.com> wrote:
> This will generate the loaders.cache file for pixbuf, at rootfs time.
>
> Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
> ---
>  meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.24.1.bb |   24 ++++++++++++--------
>  1 file changed, 14 insertions(+), 10 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 99f6cb4..c4afb97 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
> @@ -57,18 +57,22 @@ FILES_${PN}-dbg += " \
>
>  postinst_pixbufloader () {
>  if [ "x$D" != "x" ]; then
> -    exit 1
> +# Update the target's pixbuf loader's cache. Since the native binary will
> +# throw an error if the shared objects do not belong to the same ELF class,
> +# we trick the gdk-pixbuf-query-loaders into scanning the native shared
> +# objects and then we remove the NATIVE_ROOT prefix from the paths in
> +# loaders.cache.
> +gdk-pixbuf-query-loaders $(find $D/${libdir}/gdk-pixbuf-2.0/2.10.0/loaders \
> +        -name *.so | sed -e "s:$D:$NATIVE_ROOT:g") > \
> +        $D/${libdir}/gdk-pixbuf-2.0/2.10.0/loaders.cache || exit 1
> +
> +sed -i -e "s:$NATIVE_ROOT:/:g" $D/${libdir}/gdk-pixbuf-2.0/2.10.0/loaders.cache
> +



gdk-pixbuf-2.0/2.10.0 seems to be quite hardcoded. Can it be converted
into something more general may be use wildcard appropriately ?

> +exit 0
>  fi
>
> -GDK_PIXBUF_MODULEDIR=${libdir}/gdk-pixbuf-2.0/${LIBV}/loaders gdk-pixbuf-query-loaders --update-cache
> -
> -if [ -x ${bindir}/gtk-update-icon-cache ] && [ -d ${datadir}/icons ]; then
> -    for icondir in /usr/share/icons/*; do
> -        if [ -d ${icondir} ]; then
> -            gtk-update-icon-cache -t -q ${icondir}
> -        fi
> -    done
> -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
>  }
>
>  PACKAGES_DYNAMIC += "gdk-pixbuf-loader-*"
> --
> 1.7.9.5
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [RFC 5/7] gdk-pixbuf: generate the pixbuf loader's cache ar rootfs time

[Laurentiu Palcu]

On 09/19/2012 04:30 PM, Khem Raj wrote:
> On Wed, Sep 19, 2012 at 4:49 AM, Laurentiu Palcu
> <laurentiu.palcu@intel.com> wrote:
>> This will generate the loaders.cache file for pixbuf, at rootfs time.
>>
>> Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
>> ---
>>  meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.24.1.bb |   24 ++++++++++++--------
>>  1 file changed, 14 insertions(+), 10 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 99f6cb4..c4afb97 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
>> @@ -57,18 +57,22 @@ FILES_${PN}-dbg += " \
>>
>>  postinst_pixbufloader () {
>>  if [ "x$D" != "x" ]; then
>> -    exit 1
>> +# Update the target's pixbuf loader's cache. Since the native binary will
>> +# throw an error if the shared objects do not belong to the same ELF class,
>> +# we trick the gdk-pixbuf-query-loaders into scanning the native shared
>> +# objects and then we remove the NATIVE_ROOT prefix from the paths in
>> +# loaders.cache.
>> +gdk-pixbuf-query-loaders $(find $D/${libdir}/gdk-pixbuf-2.0/2.10.0/loaders \
>> +        -name *.so | sed -e "s:$D:$NATIVE_ROOT:g") > \
>> +        $D/${libdir}/gdk-pixbuf-2.0/2.10.0/loaders.cache || exit 1
>> +
>> +sed -i -e "s:$NATIVE_ROOT:/:g" $D/${libdir}/gdk-pixbuf-2.0/2.10.0/loaders.cache
>> +
> 
> 
> 
> gdk-pixbuf-2.0/2.10.0 seems to be quite hardcoded. Can it be converted
> into something more general may be use wildcard appropriately ?
I will investigate and see if I can find a more generic solution.
Basically, I just wanted to be consistent with what was already there.
I'll see what I can do.

Thanks,
Laurentiu
> 
>> +exit 0
>>  fi
>>
>> -GDK_PIXBUF_MODULEDIR=${libdir}/gdk-pixbuf-2.0/${LIBV}/loaders gdk-pixbuf-query-loaders --update-cache
>> -
>> -if [ -x ${bindir}/gtk-update-icon-cache ] && [ -d ${datadir}/icons ]; then
>> -    for icondir in /usr/share/icons/*; do
>> -        if [ -d ${icondir} ]; then
>> -            gtk-update-icon-cache -t -q ${icondir}
>> -        fi
>> -    done
>> -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
>>  }
>>
>>  PACKAGES_DYNAMIC += "gdk-pixbuf-loader-*"
>> --
>> 1.7.9.5
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[RFC 6/7] sato-icon-theme: make use of the gtk-icon-cache postinst scriptlet

[Laurentiu Palcu]

This patch is for reusing the postint scriptlet of the
gtk-icon-cache.bbclass.

Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
---
 .../sato-icon-theme/sato-icon-theme.inc            |   13 +++++++------
 1 file changed, 7 insertions(+), 6 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..3017e11 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
 
@@ -14,12 +14,13 @@ FILES_${PN} += "${datadir}"
 
 EXTRA_OECONF += "--with-iconmap=${STAGING_LIBDIR_NATIVE}/../libexec/icon-name-mapping"
 
+inherit gtk-icon-cache
+
 #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
-        fi
-        gtk-update-icon-cache -q /usr/share/icons/Sato
-        echo 'gtk-icon-theme-name = "Sato"' >> /etc/gtk-2.0/gtkrc
+	if [ ! -d $D/etc/gtk-2.0 ]; then
+		mkdir $D/etc/gtk-2.0
+	fi
+	echo 'gtk-icon-theme-name = "Sato"' >> $D/etc/gtk-2.0/gtkrc
 }
-- 
1.7.9.5

Re: [RFC 6/7] sato-icon-theme: make use of the gtk-icon-cache postinst scriptlet

[Burton, Ross]

On 19 September 2012 12:49, Laurentiu Palcu <laurentiu.palcu@intel.com> wrote:
>  SECTION = "x11"
> -DEPENDS = ""
> +DEPENDS = "gtk+-native"

This recipe doesn't directly need gtk+-native, the class does and that
already adds gtk+-native to the dependencies.

Ross

Re: [RFC 6/7] sato-icon-theme: make use of the gtk-icon-cache postinst scriptlet

[Laurentiu Palcu]

On 09/19/2012 04:36 PM, Burton, Ross wrote:
> On 19 September 2012 12:49, Laurentiu Palcu <laurentiu.palcu@intel.com> wrote:
>>  SECTION = "x11"
>> -DEPENDS = ""
>> +DEPENDS = "gtk+-native"
> 
> This recipe doesn't directly need gtk+-native, the class does and that
> already adds gtk+-native to the dependencies.
Didn't notice that... Thanks for spotting it.

Laurentiu
> 
> Ross
> 

[RFC 7/7] postinst changes: bump PR to all recipes inheriting gnome and gtk-icon-cache

[Laurentiu Palcu]

Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
---
 .../connman/connman-gnome_0.7.bb                   |    2 ++
 meta/recipes-gnome/gnome/gnome-common_2.28.0.bb    |    2 +-
 meta/recipes-gnome/gnome/gnome-desktop.inc         |    2 +-
 meta/recipes-gnome/gnome/gnome-doc-utils_0.20.6.bb |    2 +-
 meta/recipes-gnome/gnome/gnome-keyring_2.32.1.bb   |    2 +-
 meta/recipes-gnome/gnome/gnome-mime-data_2.18.0.bb |    2 +-
 meta/recipes-gnome/gnome/libgdata_0.7.1.bb         |    2 ++
 .../recipes-gnome/gnome/libgnome-keyring_2.32.0.bb |    2 +-
 meta/recipes-gnome/gnome/metacity_2.30.3.bb        |    2 +-
 meta/recipes-gnome/gthumb/gthumb_2.12.4.bb         |    2 +-
 .../gtk-engines/gtk-engines_2.20.2.bb              |    2 +-
 .../hicolor-icon-theme/hicolor-icon-theme_0.12.bb  |    2 +-
 meta/recipes-gnome/json-glib/json-glib_0.14.2.bb   |    2 +-
 meta/recipes-gnome/libglade/libglade_2.6.4.bb      |    2 +-
 meta/recipes-gnome/librsvg/librsvg_2.32.1.bb       |    2 +-
 meta/recipes-graphics/mutter/mutter_2.29.1.bb      |    2 +-
 meta/recipes-graphics/mutter/mutter_git.bb         |    2 +-
 .../sato-icon-theme/sato-icon-theme_0.4.1.bb       |    2 +-
 .../recipes-support/consolekit/consolekit_0.4.5.bb |    2 +-
 meta/recipes-support/libcroco/libcroco_0.6.3.bb    |    2 +-
 meta/recipes-support/vte/vte_0.28.2.bb             |    2 +-
 21 files changed, 23 insertions(+), 19 deletions(-)

diff --git a/meta/recipes-connectivity/connman/connman-gnome_0.7.bb b/meta/recipes-connectivity/connman/connman-gnome_0.7.bb
index 6cceb2d..1f0c9c0 100644
--- a/meta/recipes-connectivity/connman/connman-gnome_0.7.bb
+++ b/meta/recipes-connectivity/connman/connman-gnome_0.7.bb
@@ -12,6 +12,8 @@ DEPENDS = "gtk+ dbus-glib"
 SRCREV = "cf3c325b23dae843c5499a113591cfbc98acb143"
 SRC_URI = "git://github.com/connectivity/connman-gnome.git;protocol=git"
 
+PR = "r1"
+
 S = "${WORKDIR}/git"
 
 inherit autotools gtk-icon-cache
diff --git a/meta/recipes-gnome/gnome/gnome-common_2.28.0.bb b/meta/recipes-gnome/gnome/gnome-common_2.28.0.bb
index 8936dbd..9bc4e85 100644
--- a/meta/recipes-gnome/gnome/gnome-common_2.28.0.bb
+++ b/meta/recipes-gnome/gnome/gnome-common_2.28.0.bb
@@ -6,7 +6,7 @@ LICENSE = "GPLv3"
 LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
 
 SECTION = "x11/gnome"
-PR = "r1"
+PR = "r2"
 inherit gnome allarch
 
 # The omf.make file failed if scrollkeeper doesn't happen to be
diff --git a/meta/recipes-gnome/gnome/gnome-desktop.inc b/meta/recipes-gnome/gnome/gnome-desktop.inc
index 4687a7b..188446a 100644
--- a/meta/recipes-gnome/gnome/gnome-desktop.inc
+++ b/meta/recipes-gnome/gnome/gnome-desktop.inc
@@ -11,7 +11,7 @@ do_configure_prepend () {
 
 FILES_${PN} += "${datadir}/gnome-about ${datadir}/libgnome-desktop/pnp.ids"
 
-PR = "r6"
+PR = "r7"
 
 inherit gnome pkgconfig
 
diff --git a/meta/recipes-gnome/gnome/gnome-doc-utils_0.20.6.bb b/meta/recipes-gnome/gnome/gnome-doc-utils_0.20.6.bb
index e93f584..3c38150 100644
--- a/meta/recipes-gnome/gnome/gnome-doc-utils_0.20.6.bb
+++ b/meta/recipes-gnome/gnome/gnome-doc-utils_0.20.6.bb
@@ -1,7 +1,7 @@
 require gnome-doc-utils.inc
 LIC_FILES_CHKSUM = "file://COPYING.GPL;md5=eb723b61539feef013de476e68b5c50a \
 		    file://COPYING.LGPL;md5=a6f89e2100d9b6cdffcea4f398e37343"
-PR = "r8"
+PR = "r9"
 
 SRC_URI += "file://xsltproc_nonet.patch \
 	    file://use-usr-bin-env-for-python-in-xml2po.patch \
diff --git a/meta/recipes-gnome/gnome/gnome-keyring_2.32.1.bb b/meta/recipes-gnome/gnome/gnome-keyring_2.32.1.bb
index 1fd42b4..d822721 100644
--- a/meta/recipes-gnome/gnome/gnome-keyring_2.32.1.bb
+++ b/meta/recipes-gnome/gnome/gnome-keyring_2.32.1.bb
@@ -11,7 +11,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
 
 SECTION = "x11/gnome"
 
-PR = "r8"
+PR = "r9"
 
 inherit autotools gnome gtk-doc pkgconfig
 
diff --git a/meta/recipes-gnome/gnome/gnome-mime-data_2.18.0.bb b/meta/recipes-gnome/gnome/gnome-mime-data_2.18.0.bb
index fc891c7..3670912 100644
--- a/meta/recipes-gnome/gnome/gnome-mime-data_2.18.0.bb
+++ b/meta/recipes-gnome/gnome/gnome-mime-data_2.18.0.bb
@@ -8,7 +8,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=59530bdf33659b29e73d4adb9f9f6552 \
 
 inherit gnome
 inherit autotools
-PR = "r4"
+PR = "r5"
 
 SRC_URI += "file://pkgconfig.patch"
 
diff --git a/meta/recipes-gnome/gnome/libgdata_0.7.1.bb b/meta/recipes-gnome/gnome/libgdata_0.7.1.bb
index c3f4047..e12ed70 100644
--- a/meta/recipes-gnome/gnome/libgdata_0.7.1.bb
+++ b/meta/recipes-gnome/gnome/libgdata_0.7.1.bb
@@ -13,3 +13,5 @@ inherit gnome pkgconfig autotools gettext
 
 SRC_URI[archive.md5sum] = "ec5262cbcb07b63b58d45aa3ac636096"
 SRC_URI[archive.sha256sum] = "fb244138276a5ce98510b0e2408bbf6f9ce0fd8cdcf86f07cd4be38afbb7c2bc"
+
+PR = "r1"
diff --git a/meta/recipes-gnome/gnome/libgnome-keyring_2.32.0.bb b/meta/recipes-gnome/gnome/libgnome-keyring_2.32.0.bb
index 8ed44f3..3d8bd4f 100644
--- a/meta/recipes-gnome/gnome/libgnome-keyring_2.32.0.bb
+++ b/meta/recipes-gnome/gnome/libgnome-keyring_2.32.0.bb
@@ -9,7 +9,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=0914b9d3ebaba41ef2e3e0ae16f296cf \
                     file://egg/egg-dh.h;endline=22;md5=1626c16af2a8da1f88324cf3ced33f08"
 
 SECTION = "x11/gnome/libs"
-PR = "r3"
+PR = "r4"
 
 inherit gnome gtk-doc
 
diff --git a/meta/recipes-gnome/gnome/metacity_2.30.3.bb b/meta/recipes-gnome/gnome/metacity_2.30.3.bb
index 3524f0e..5536fc3 100644
--- a/meta/recipes-gnome/gnome/metacity_2.30.3.bb
+++ b/meta/recipes-gnome/gnome/metacity_2.30.3.bb
@@ -5,7 +5,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
                     file://src/include/main.h;endline=24;md5=c2242df552c880280315989bab626b90"
 
 DEPENDS = "startup-notification gtk+ gconf gdk-pixbuf-native libcanberra gnome-doc-utils"
-PR = "r5"
+PR = "r6"
 
 inherit gnome update-alternatives
 
diff --git a/meta/recipes-gnome/gthumb/gthumb_2.12.4.bb b/meta/recipes-gnome/gthumb/gthumb_2.12.4.bb
index 0414386..c62ffa3 100644
--- a/meta/recipes-gnome/gthumb/gthumb_2.12.4.bb
+++ b/meta/recipes-gnome/gthumb/gthumb_2.12.4.bb
@@ -4,7 +4,7 @@ LICENSE = "GPLv2"
 LIC_FILES_CHKSUM = "file://COPYING;md5=59530bdf33659b29e73d4adb9f9f6552"
 DEPENDS = "glib-2.0 gtk+ libxml2 gnome-doc-utils libunique gconf libpng gstreamer jpeg tiff gst-plugins-base"
 
-PR = "r4"
+PR = "r5"
 
 EXTRA_OECONF = "--disable-gnome-keyring --disable-libsoup --disable-exiv2 --disable-clutter"
 
diff --git a/meta/recipes-gnome/gtk-engines/gtk-engines_2.20.2.bb b/meta/recipes-gnome/gtk-engines/gtk-engines_2.20.2.bb
index c544870..259517e 100644
--- a/meta/recipes-gnome/gtk-engines/gtk-engines_2.20.2.bb
+++ b/meta/recipes-gnome/gtk-engines/gtk-engines_2.20.2.bb
@@ -8,7 +8,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=2d5025d4aa3495befef8f17206a5b0a1"
 SECTION = "x11/base"
 DEPENDS = "gtk+"
 
-PR = "r2"
+PR = "r3"
 
 PACKAGES_DYNAMIC = "gtk-engine-* gtk-theme-*"
 
diff --git a/meta/recipes-gnome/hicolor-icon-theme/hicolor-icon-theme_0.12.bb b/meta/recipes-gnome/hicolor-icon-theme/hicolor-icon-theme_0.12.bb
index 759c9d8..7c911e0 100644
--- a/meta/recipes-gnome/hicolor-icon-theme/hicolor-icon-theme_0.12.bb
+++ b/meta/recipes-gnome/hicolor-icon-theme/hicolor-icon-theme_0.12.bb
@@ -10,7 +10,7 @@ inherit gnome allarch
 
 DEPENDS = ""
 
-PR = "r0"
+PR = "r1"
 
 SRC_URI = "http://icon-theme.freedesktop.org/releases/${BPN}-${PV}.tar.gz \
         file://index.theme"
diff --git a/meta/recipes-gnome/json-glib/json-glib_0.14.2.bb b/meta/recipes-gnome/json-glib/json-glib_0.14.2.bb
index 18db4e7..a4cbd51 100644
--- a/meta/recipes-gnome/json-glib/json-glib_0.14.2.bb
+++ b/meta/recipes-gnome/json-glib/json-glib_0.14.2.bb
@@ -8,7 +8,7 @@ HOMEPAGE = "http://live.gnome.org/JsonGlib"
 LICENSE = "LGPLv2.1"
 LIC_FILES_CHKSUM = "file://COPYING;md5=7fbc338309ac38fefcd64b04bb903e34"
 
-PR = "r1"
+PR = "r2"
 
 DEPENDS = "glib-2.0"
 
diff --git a/meta/recipes-gnome/libglade/libglade_2.6.4.bb b/meta/recipes-gnome/libglade/libglade_2.6.4.bb
index 0b01dc1..c8a2fac 100644
--- a/meta/recipes-gnome/libglade/libglade_2.6.4.bb
+++ b/meta/recipes-gnome/libglade/libglade_2.6.4.bb
@@ -8,7 +8,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=55ca817ccb7d5b5b66355690e9abc605 \
                     file://glade/glade-gtk.c;endline=22;md5=766f993433e2642fec87936d319990ff"
 
 SECTION = "libs"
-PR = "r4"
+PR = "r5"
 DEPENDS = "zlib gdk-pixbuf gtk+"
 
 inherit autotools pkgconfig gnome gtk-doc
diff --git a/meta/recipes-gnome/librsvg/librsvg_2.32.1.bb b/meta/recipes-gnome/librsvg/librsvg_2.32.1.bb
index 6bb5fe2..12ae310 100644
--- a/meta/recipes-gnome/librsvg/librsvg_2.32.1.bb
+++ b/meta/recipes-gnome/librsvg/librsvg_2.32.1.bb
@@ -11,7 +11,7 @@ DEPENDS = "gtk+ libcroco cairo libxml2"
 DEPENDS_virtclass-native = "cairo-native pango-native gdk-pixbuf-native"
 BBCLASSEXTEND = "native"
 
-PR = "r9"
+PR = "r10"
 
 inherit autotools pkgconfig gnome gtk-doc
 
diff --git a/meta/recipes-graphics/mutter/mutter_2.29.1.bb b/meta/recipes-graphics/mutter/mutter_2.29.1.bb
index aefd2c7..6a88441 100644
--- a/meta/recipes-graphics/mutter/mutter_2.29.1.bb
+++ b/meta/recipes-graphics/mutter/mutter_2.29.1.bb
@@ -1,6 +1,6 @@
 require mutter.inc
 
-PR = "r1"
+PR = "r2"
 
 LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f"
 
diff --git a/meta/recipes-graphics/mutter/mutter_git.bb b/meta/recipes-graphics/mutter/mutter_git.bb
index 94cb17d..c151a1d 100644
--- a/meta/recipes-graphics/mutter/mutter_git.bb
+++ b/meta/recipes-graphics/mutter/mutter_git.bb
@@ -2,7 +2,7 @@ require mutter.inc
 
 SRCREV = "01d3bebe24d2a56bdf2d82c4a71923e1573f7b7c"
 PV = "2.29.1+git${SRCPV}"
-PR = "r0"
+PR = "r1"
 
 LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f"
 
diff --git a/meta/recipes-sato/sato-icon-theme/sato-icon-theme_0.4.1.bb b/meta/recipes-sato/sato-icon-theme/sato-icon-theme_0.4.1.bb
index 108f8e8..6405359 100644
--- a/meta/recipes-sato/sato-icon-theme/sato-icon-theme_0.4.1.bb
+++ b/meta/recipes-sato/sato-icon-theme/sato-icon-theme_0.4.1.bb
@@ -2,7 +2,7 @@ require sato-icon-theme.inc
 
 DEPENDS += "icon-naming-utils-native"
 
-PR = "r3"
+PR = "r4"
 
 SRC_URI = "http://pokylinux.org/releases/sato/${BPN}-${PV}.tar.gz \
            file://iconpath-option.patch \
diff --git a/meta/recipes-support/consolekit/consolekit_0.4.5.bb b/meta/recipes-support/consolekit/consolekit_0.4.5.bb
index d1cc037..b68500f 100644
--- a/meta/recipes-support/consolekit/consolekit_0.4.5.bb
+++ b/meta/recipes-support/consolekit/consolekit_0.4.5.bb
@@ -2,7 +2,7 @@ DESCRIPTION = "ConsoleKit is a framework for defining and tracking users, login
 HOMEPAGE="http://www.freedesktop.org/wiki/Software/ConsoleKit"
 BUGTRACKER="https://bugs.freedesktop.org/buglist.cgi?query_format=specific&product=ConsoleKit"
 
-PR = "r9"
+PR = "r10"
 
 LICENSE = "GPLv2+"
 LIC_FILES_CHKSUM = "file://COPYING;md5=59530bdf33659b29e73d4adb9f9f6552 \
diff --git a/meta/recipes-support/libcroco/libcroco_0.6.3.bb b/meta/recipes-support/libcroco/libcroco_0.6.3.bb
index d9ff8de..d11462b 100644
--- a/meta/recipes-support/libcroco/libcroco_0.6.3.bb
+++ b/meta/recipes-support/libcroco/libcroco_0.6.3.bb
@@ -9,7 +9,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=55ca817ccb7d5b5b66355690e9abc605 \
 
 SECTION = "x11/utils"
 DEPENDS = "glib-2.0 libxml2 zlib"
-PR = "r3"
+PR = "r4"
 
 inherit autotools pkgconfig gnome
 
diff --git a/meta/recipes-support/vte/vte_0.28.2.bb b/meta/recipes-support/vte/vte_0.28.2.bb
index 2cb1871..1fe66e7 100644
--- a/meta/recipes-support/vte/vte_0.28.2.bb
+++ b/meta/recipes-support/vte/vte_0.28.2.bb
@@ -2,7 +2,7 @@ require vte.inc
 
 LIC_FILES_CHKSUM = "file://COPYING;md5=3bf50002aefd002f49e7bb854063f7e7"
 
-PR = "r4"
+PR = "r5"
 
 SRC_URI[archive.md5sum] = "f07a4bf943194f94b7f142db8f7f36dc"
 SRC_URI[archive.sha256sum] = "8d04e202b617373dfb47689e5e628febe2c58840b34cccc4af4feb88c48df903"
-- 
1.7.9.5

Re: [RFC 0/7] Postinstall improvements

[Andreas Müller]

On Wed, Sep 19, 2012 at 5:33 PM, Laurentiu Palcu
<laurentiu.palcu@intel.com> wrote:
>
>
> On 09/19/2012 04:41 PM, Andreas Müller wrote:
>> On Wed, Sep 19, 2012 at 1:49 PM, Laurentiu Palcu
>> <laurentiu.palcu@intel.com> wrote:
>>> Hi,
>>>
>>> It's been quite a long time since I sent the first version of postinstall
>>> improvements which, after some debate, we decided it needed run-once
>>> support of postinst scriptlets on host. This patcheset (RFC actually) adds
>>> that.
>>>
>>> So, in order to achieve this goal I took advantage of
>>> ROOTFS_POSTPROCESS_COMMAND variable. Basically, if running some postinst
>>> scriptlets is time consuming (even on host) and execute repeatedly,
>>> then we can postpone the running and run the scriplet just once. The idea is
>>> to put the scriptlet in the ${WORKDIR}/intercept_scripts directory. When the
>>> ROOTFS_POSTPROCESS_COMMAND is executed, it will pick up all the scripts in
>>> this directory and execute them.
>>>
>>> This actual patchset does the above for the gtk icon cache generation which
>>> takes a very long time to run on target and even on some hosts.
>>>
>>> The people willing to give this patchset a test, are most than welcome. Also,
>>> please feel free to review.
>>>
>>> Thanks,
>>> Laurentiu
>>>
>> Thanks for taking care. I will give it a test tonight and hope to have
>> results tomorrow.
> It would be great if you could give it a try and let me know your results.
>
I removed gtk-native append in meta-oe, build from scratch and tested
the image. No issues so far - seems you have done a great job -
Thanks!

Andreas

Re: [RFC 0/7] Postinstall improvements

[Andreas Müller]

On Thu, Sep 20, 2012 at 5:38 PM, Andreas Müller
<schnitzeltony@googlemail.com> wrote:
> On Wed, Sep 19, 2012 at 5:33 PM, Laurentiu Palcu
> <laurentiu.palcu@intel.com> wrote:
>>
>>
>> On 09/19/2012 04:41 PM, Andreas Müller wrote:
>>> On Wed, Sep 19, 2012 at 1:49 PM, Laurentiu Palcu
>>> <laurentiu.palcu@intel.com> wrote:
>>>> Hi,
>>>>
>>>> It's been quite a long time since I sent the first version of postinstall
>>>> improvements which, after some debate, we decided it needed run-once
>>>> support of postinst scriptlets on host. This patcheset (RFC actually) adds
>>>> that.
>>>>
>>>> So, in order to achieve this goal I took advantage of
>>>> ROOTFS_POSTPROCESS_COMMAND variable. Basically, if running some postinst
>>>> scriptlets is time consuming (even on host) and execute repeatedly,
>>>> then we can postpone the running and run the scriplet just once. The idea is
>>>> to put the scriptlet in the ${WORKDIR}/intercept_scripts directory. When the
>>>> ROOTFS_POSTPROCESS_COMMAND is executed, it will pick up all the scripts in
>>>> this directory and execute them.
>>>>
>>>> This actual patchset does the above for the gtk icon cache generation which
>>>> takes a very long time to run on target and even on some hosts.
>>>>
>>>> The people willing to give this patchset a test, are most than welcome. Also,
>>>> please feel free to review.
>>>>
>>>> Thanks,
>>>> Laurentiu
>>>>
>>> Thanks for taking care. I will give it a test tonight and hope to have
>>> results tomorrow.
>> It would be great if you could give it a try and let me know your results.
>>
> I removed gtk-native append in meta-oe, build from scratch and tested
> the image. No issues so far - seems you have done a great job -
> Thanks!
>
Aargh I really would like to consider this done but I found suspicious
when browsing on the machine with the new image (hicolor- and
gnome-icon-theme installed):

* in the folder /usr/share/icons/gnome *no* icon-theme.cache is found
* /usr/share/icons/hicolor/icon-theme.cache is there but it has the
date of 01.01.2000 (have no rtc backup on the machine). I would expect
this file to have build host's date.

So I checked the contents on the build machine in image's rootfs:

* in the folder /usr/share/icons/gnome *no* icon-theme.cache is found
* /usr/share/icons/hicolor/icon-theme.cache is there but has only
64,5KB (the version on the machine is 2,3MB!!).


Andreas

Re: [RFC 0/7] Postinstall improvements

[Laurentiu Palcu]

On 09/20/2012 07:12 PM, Andreas Müller wrote:
> On Thu, Sep 20, 2012 at 5:38 PM, Andreas Müller
> <schnitzeltony@googlemail.com> wrote:
>> On Wed, Sep 19, 2012 at 5:33 PM, Laurentiu Palcu
>> <laurentiu.palcu@intel.com> wrote:
>>>
>>>
>>> On 09/19/2012 04:41 PM, Andreas Müller wrote:
>>>> On Wed, Sep 19, 2012 at 1:49 PM, Laurentiu Palcu
>>>> <laurentiu.palcu@intel.com> wrote:
>>>>> Hi,
>>>>>
>>>>> It's been quite a long time since I sent the first version of postinstall
>>>>> improvements which, after some debate, we decided it needed run-once
>>>>> support of postinst scriptlets on host. This patcheset (RFC actually) adds
>>>>> that.
>>>>>
>>>>> So, in order to achieve this goal I took advantage of
>>>>> ROOTFS_POSTPROCESS_COMMAND variable. Basically, if running some postinst
>>>>> scriptlets is time consuming (even on host) and execute repeatedly,
>>>>> then we can postpone the running and run the scriplet just once. The idea is
>>>>> to put the scriptlet in the ${WORKDIR}/intercept_scripts directory. When the
>>>>> ROOTFS_POSTPROCESS_COMMAND is executed, it will pick up all the scripts in
>>>>> this directory and execute them.
>>>>>
>>>>> This actual patchset does the above for the gtk icon cache generation which
>>>>> takes a very long time to run on target and even on some hosts.
>>>>>
>>>>> The people willing to give this patchset a test, are most than welcome. Also,
>>>>> please feel free to review.
>>>>>
>>>>> Thanks,
>>>>> Laurentiu
>>>>>
>>>> Thanks for taking care. I will give it a test tonight and hope to have
>>>> results tomorrow.
>>> It would be great if you could give it a try and let me know your results.
>>>
>> I removed gtk-native append in meta-oe, build from scratch and tested
Any special reason you removed it?

>> the image. No issues so far - seems you have done a great job -
>> Thanks!
>>
> Aargh I really would like to consider this done but I found suspicious
> when browsing on the machine with the new image (hicolor- and
> gnome-icon-theme installed):
Let's hope we'll have it done soon. Thanks a lot for testing it. Can you
instruct me what image did you use and give some more details in order
to debug it on my side?

> 
> * in the folder /usr/share/icons/gnome *no* icon-theme.cache is found
> * /usr/share/icons/hicolor/icon-theme.cache is there but it has the
> date of 01.01.2000 (have no rtc backup on the machine). I would expect
> this file to have build host's date.
> 
> So I checked the contents on the build machine in image's rootfs:
> 
> * in the folder /usr/share/icons/gnome *no* icon-theme.cache is found
That's weird... You could add some debug info in the intercept script
itself to see if it really scans the gnome directory and if there are
any errors.

> * /usr/share/icons/hicolor/icon-theme.cache is there but has only
> 64,5KB (the version on the machine is 2,3MB!!).
On my build machine (I used Sato image) the icon-theme.cache has 2.5MB.
There must be something wrong somewhere... At least this directory
should have been cached properly.

If you give all the details I asked above, I'll give it a try myself.
> 
> 
> Andreas
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> 

Re: [RFC 0/7] Postinstall improvements

[Martin Jansa]

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

On Thu, Sep 20, 2012 at 09:15:02PM +0300, Laurentiu Palcu wrote:
> 
> 
> On 09/20/2012 07:12 PM, Andreas Müller wrote:
> > On Thu, Sep 20, 2012 at 5:38 PM, Andreas Müller
> > <schnitzeltony@googlemail.com> wrote:
> >> On Wed, Sep 19, 2012 at 5:33 PM, Laurentiu Palcu
> >> <laurentiu.palcu@intel.com> wrote:
> >>>
> >>>
> >>> On 09/19/2012 04:41 PM, Andreas Müller wrote:
> >>>> On Wed, Sep 19, 2012 at 1:49 PM, Laurentiu Palcu
> >>>> <laurentiu.palcu@intel.com> wrote:
> >>>>> Hi,
> >>>>>
> >>>>> It's been quite a long time since I sent the first version of postinstall
> >>>>> improvements which, after some debate, we decided it needed run-once
> >>>>> support of postinst scriptlets on host. This patcheset (RFC actually) adds
> >>>>> that.
> >>>>>
> >>>>> So, in order to achieve this goal I took advantage of
> >>>>> ROOTFS_POSTPROCESS_COMMAND variable. Basically, if running some postinst
> >>>>> scriptlets is time consuming (even on host) and execute repeatedly,
> >>>>> then we can postpone the running and run the scriplet just once. The idea is
> >>>>> to put the scriptlet in the ${WORKDIR}/intercept_scripts directory. When the
> >>>>> ROOTFS_POSTPROCESS_COMMAND is executed, it will pick up all the scripts in
> >>>>> this directory and execute them.
> >>>>>
> >>>>> This actual patchset does the above for the gtk icon cache generation which
> >>>>> takes a very long time to run on target and even on some hosts.
> >>>>>
> >>>>> The people willing to give this patchset a test, are most than welcome. Also,
> >>>>> please feel free to review.
> >>>>>
> >>>>> Thanks,
> >>>>> Laurentiu
> >>>>>
> >>>> Thanks for taking care. I will give it a test tonight and hope to have
> >>>> results tomorrow.
> >>> It would be great if you could give it a try and let me know your results.
> >>>
> >> I removed gtk-native append in meta-oe, build from scratch and tested
> Any special reason you removed it?

That BBCLASSEXTEND was in meta-oe for long time (for gtk+3):

http://lists.linuxtogo.org/pipermail/openembedded-commits/2012-January/062622.html

Last time I've tried to merge that .bbappend to oe-core it was refused:
http://lists.linuxtogo.org/pipermail/openembedded-core/2012-March/019648.html

But now it's in oe-core and there is no reason to keep it in meta-oe too.

Cheers,

> 
> >> the image. No issues so far - seems you have done a great job -
> >> Thanks!
> >>
> > Aargh I really would like to consider this done but I found suspicious
> > when browsing on the machine with the new image (hicolor- and
> > gnome-icon-theme installed):
> Let's hope we'll have it done soon. Thanks a lot for testing it. Can you
> instruct me what image did you use and give some more details in order
> to debug it on my side?
> 
> > 
> > * in the folder /usr/share/icons/gnome *no* icon-theme.cache is found
> > * /usr/share/icons/hicolor/icon-theme.cache is there but it has the
> > date of 01.01.2000 (have no rtc backup on the machine). I would expect
> > this file to have build host's date.
> > 
> > So I checked the contents on the build machine in image's rootfs:
> > 
> > * in the folder /usr/share/icons/gnome *no* icon-theme.cache is found
> That's weird... You could add some debug info in the intercept script
> itself to see if it really scans the gnome directory and if there are
> any errors.
> 
> > * /usr/share/icons/hicolor/icon-theme.cache is there but has only
> > 64,5KB (the version on the machine is 2,3MB!!).
> On my build machine (I used Sato image) the icon-theme.cache has 2.5MB.
> There must be something wrong somewhere... At least this directory
> should have been cached properly.
> 
> If you give all the details I asked above, I'll give it a try myself.
> > 
> > 
> > Andreas
> > 
> > _______________________________________________
> > 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

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

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

Re: [RFC 0/7] Postinstall improvements

[Laurentiu Palcu]

On 09/20/2012 07:12 PM, Andreas Müller wrote:
> On Thu, Sep 20, 2012 at 5:38 PM, Andreas Müller
> <schnitzeltony@googlemail.com> wrote:
>> On Wed, Sep 19, 2012 at 5:33 PM, Laurentiu Palcu
>> <laurentiu.palcu@intel.com> wrote:
>>>
>>>
>>> On 09/19/2012 04:41 PM, Andreas Müller wrote:
>>>> On Wed, Sep 19, 2012 at 1:49 PM, Laurentiu Palcu
>>>> <laurentiu.palcu@intel.com> wrote:
>>>>> Hi,
>>>>>
>>>>> It's been quite a long time since I sent the first version of postinstall
>>>>> improvements which, after some debate, we decided it needed run-once
>>>>> support of postinst scriptlets on host. This patcheset (RFC actually) adds
>>>>> that.
>>>>>
>>>>> So, in order to achieve this goal I took advantage of
>>>>> ROOTFS_POSTPROCESS_COMMAND variable. Basically, if running some postinst
>>>>> scriptlets is time consuming (even on host) and execute repeatedly,
>>>>> then we can postpone the running and run the scriplet just once. The idea is
>>>>> to put the scriptlet in the ${WORKDIR}/intercept_scripts directory. When the
>>>>> ROOTFS_POSTPROCESS_COMMAND is executed, it will pick up all the scripts in
>>>>> this directory and execute them.
>>>>>
>>>>> This actual patchset does the above for the gtk icon cache generation which
>>>>> takes a very long time to run on target and even on some hosts.
>>>>>
>>>>> The people willing to give this patchset a test, are most than welcome. Also,
>>>>> please feel free to review.
>>>>>
>>>>> Thanks,
>>>>> Laurentiu
>>>>>
>>>> Thanks for taking care. I will give it a test tonight and hope to have
>>>> results tomorrow.
>>> It would be great if you could give it a try and let me know your results.
>>>
>> I removed gtk-native append in meta-oe, build from scratch and tested
>> the image. No issues so far - seems you have done a great job -
>> Thanks!
>>
> Aargh I really would like to consider this done but I found suspicious
> when browsing on the machine with the new image (hicolor- and
> gnome-icon-theme installed):
> 
> * in the folder /usr/share/icons/gnome *no* icon-theme.cache is found
> * /usr/share/icons/hicolor/icon-theme.cache is there but it has the
> date of 01.01.2000 (have no rtc backup on the machine). I would expect
> this file to have build host's date.
> 
> So I checked the contents on the build machine in image's rootfs:
> 
> * in the folder /usr/share/icons/gnome *no* icon-theme.cache is found
> * /usr/share/icons/hicolor/icon-theme.cache is there but has only
> 64,5KB (the version on the machine is 2,3MB!!).
Did you have any chance to debug the issue on your setup? I tried to
replicate your environment but I failed. Lots of build errors, so I gave
up. It would have taken me more time to make your setup work than
debugging the real problem.

Another alternative would be for you to prepare a tarball with all the
repos and configs that you use and put it somewhere where I can take it.
It would be easier for me to directly start debugging your issue.

Thanks,
Laurentiu
> 
> 
> Andreas
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> 

Re: [RFC 0/7] Postinstall improvements

[Andreas Müller]

On Wed, Sep 26, 2012 at 9:09 AM, Laurentiu Palcu
<laurentiu.palcu@intel.com> wrote:
>
>
> On 09/20/2012 07:12 PM, Andreas Müller wrote:
>> On Thu, Sep 20, 2012 at 5:38 PM, Andreas Müller
>> <schnitzeltony@googlemail.com> wrote:
>>> On Wed, Sep 19, 2012 at 5:33 PM, Laurentiu Palcu
>>> <laurentiu.palcu@intel.com> wrote:
>>>>
>>>>
>>>> On 09/19/2012 04:41 PM, Andreas Müller wrote:
>>>>> On Wed, Sep 19, 2012 at 1:49 PM, Laurentiu Palcu
>>>>> <laurentiu.palcu@intel.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> It's been quite a long time since I sent the first version of postinstall
>>>>>> improvements which, after some debate, we decided it needed run-once
>>>>>> support of postinst scriptlets on host. This patcheset (RFC actually) adds
>>>>>> that.
>>>>>>
>>>>>> So, in order to achieve this goal I took advantage of
>>>>>> ROOTFS_POSTPROCESS_COMMAND variable. Basically, if running some postinst
>>>>>> scriptlets is time consuming (even on host) and execute repeatedly,
>>>>>> then we can postpone the running and run the scriplet just once. The idea is
>>>>>> to put the scriptlet in the ${WORKDIR}/intercept_scripts directory. When the
>>>>>> ROOTFS_POSTPROCESS_COMMAND is executed, it will pick up all the scripts in
>>>>>> this directory and execute them.
>>>>>>
>>>>>> This actual patchset does the above for the gtk icon cache generation which
>>>>>> takes a very long time to run on target and even on some hosts.
>>>>>>
>>>>>> The people willing to give this patchset a test, are most than welcome. Also,
>>>>>> please feel free to review.
>>>>>>
>>>>>> Thanks,
>>>>>> Laurentiu
>>>>>>
>>>>> Thanks for taking care. I will give it a test tonight and hope to have
>>>>> results tomorrow.
>>>> It would be great if you could give it a try and let me know your results.
>>>>
>>> I removed gtk-native append in meta-oe, build from scratch and tested
>>> the image. No issues so far - seems you have done a great job -
>>> Thanks!
>>>
>> Aargh I really would like to consider this done but I found suspicious
>> when browsing on the machine with the new image (hicolor- and
>> gnome-icon-theme installed):
>>
>> * in the folder /usr/share/icons/gnome *no* icon-theme.cache is found
>> * /usr/share/icons/hicolor/icon-theme.cache is there but it has the
>> date of 01.01.2000 (have no rtc backup on the machine). I would expect
>> this file to have build host's date.
>>
>> So I checked the contents on the build machine in image's rootfs:
>>
>> * in the folder /usr/share/icons/gnome *no* icon-theme.cache is found
>> * /usr/share/icons/hicolor/icon-theme.cache is there but has only
>> 64,5KB (the version on the machine is 2,3MB!!).
> Did you have any chance to debug the issue on your setup? I tried to
> replicate your environment but I failed. Lots of build errors, so I gave
> up. It would have taken me more time to make your setup work than
> debugging the real problem.
>
> Another alternative would be for you to prepare a tarball with all the
> repos and configs that you use and put it somewhere where I can take it.
> It would be easier for me to directly start debugging your issue.
>
Sorry but I am occupied by other issues at the moment. Hope to find
time at the weekend to add some debug messages to see what's going on.

Andreas

Re: [RFC 0/7] Postinstall improvements

[Andreas Müller]

On Wed, Sep 26, 2012 at 9:41 AM, Andreas Müller
<schnitzeltony@googlemail.com> wrote:
> On Wed, Sep 26, 2012 at 9:09 AM, Laurentiu Palcu
> <laurentiu.palcu@intel.com> wrote:
>>
>>
>> On 09/20/2012 07:12 PM, Andreas Müller wrote:
>>> On Thu, Sep 20, 2012 at 5:38 PM, Andreas Müller
>>> <schnitzeltony@googlemail.com> wrote:
>>>> On Wed, Sep 19, 2012 at 5:33 PM, Laurentiu Palcu
>>>> <laurentiu.palcu@intel.com> wrote:
>>>>>
>>>>>
>>>>> On 09/19/2012 04:41 PM, Andreas Müller wrote:
>>>>>> On Wed, Sep 19, 2012 at 1:49 PM, Laurentiu Palcu
>>>>>> <laurentiu.palcu@intel.com> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> It's been quite a long time since I sent the first version of postinstall
>>>>>>> improvements which, after some debate, we decided it needed run-once
>>>>>>> support of postinst scriptlets on host. This patcheset (RFC actually) adds
>>>>>>> that.
>>>>>>>
>>>>>>> So, in order to achieve this goal I took advantage of
>>>>>>> ROOTFS_POSTPROCESS_COMMAND variable. Basically, if running some postinst
>>>>>>> scriptlets is time consuming (even on host) and execute repeatedly,
>>>>>>> then we can postpone the running and run the scriplet just once. The idea is
>>>>>>> to put the scriptlet in the ${WORKDIR}/intercept_scripts directory. When the
>>>>>>> ROOTFS_POSTPROCESS_COMMAND is executed, it will pick up all the scripts in
>>>>>>> this directory and execute them.
>>>>>>>
>>>>>>> This actual patchset does the above for the gtk icon cache generation which
>>>>>>> takes a very long time to run on target and even on some hosts.
>>>>>>>
>>>>>>> The people willing to give this patchset a test, are most than welcome. Also,
>>>>>>> please feel free to review.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Laurentiu
>>>>>>>
>>>>>> Thanks for taking care. I will give it a test tonight and hope to have
>>>>>> results tomorrow.
>>>>> It would be great if you could give it a try and let me know your results.
>>>>>
>>>> I removed gtk-native append in meta-oe, build from scratch and tested
>>>> the image. No issues so far - seems you have done a great job -
>>>> Thanks!
>>>>
>>> Aargh I really would like to consider this done but I found suspicious
>>> when browsing on the machine with the new image (hicolor- and
>>> gnome-icon-theme installed):
>>>
>>> * in the folder /usr/share/icons/gnome *no* icon-theme.cache is found
>>> * /usr/share/icons/hicolor/icon-theme.cache is there but it has the
>>> date of 01.01.2000 (have no rtc backup on the machine). I would expect
>>> this file to have build host's date.
>>>
>>> So I checked the contents on the build machine in image's rootfs:
>>>
>>> * in the folder /usr/share/icons/gnome *no* icon-theme.cache is found
>>> * /usr/share/icons/hicolor/icon-theme.cache is there but has only
>>> 64,5KB (the version on the machine is 2,3MB!!).
>> Did you have any chance to debug the issue on your setup? I tried to
>> replicate your environment but I failed. Lots of build errors, so I gave
>> up. It would have taken me more time to make your setup work than
>> debugging the real problem.
>>
>> Another alternative would be for you to prepare a tarball with all the
>> repos and configs that you use and put it somewhere where I can take it.
>> It would be easier for me to directly start debugging your issue.
>>
> Sorry but I am occupied by other issues at the moment. Hope to find
> time at the weekend to add some debug messages to see what's going on.
>
Oh it's that simple: run_intercept_scriptlets is not called here (I
don't know what caused 'mini hicolor-icon-theme's cache)! You can
reproduce that e.g. by enabling buildhistory.

I simply replaced in image.bbclass

ROOTFS_POSTPROCESS_COMMAND ?= "run_intercept_scriptlets"
by
ROOTFS_POSTPROCESS_COMMAND =+ "run_intercept_scriptlets;"

an now see larger caches for all my icon themes. But the sizes are
still different from those mentioned above. Will run-test tomorrow.

Andreas

Re: [RFC 0/7] Postinstall improvements

[Andreas Müller]

On Thu, Oct 4, 2012 at 1:37 AM, Andreas Müller
<schnitzeltony@googlemail.com> wrote:
> On Wed, Sep 26, 2012 at 9:41 AM, Andreas Müller
> <schnitzeltony@googlemail.com> wrote:
>> On Wed, Sep 26, 2012 at 9:09 AM, Laurentiu Palcu
>> <laurentiu.palcu@intel.com> wrote:
>>>
>>>
>>> On 09/20/2012 07:12 PM, Andreas Müller wrote:
>>>> On Thu, Sep 20, 2012 at 5:38 PM, Andreas Müller
>>>> <schnitzeltony@googlemail.com> wrote:
>>>>> On Wed, Sep 19, 2012 at 5:33 PM, Laurentiu Palcu
>>>>> <laurentiu.palcu@intel.com> wrote:
>>>>>>
>>>>>>
>>>>>> On 09/19/2012 04:41 PM, Andreas Müller wrote:
>>>>>>> On Wed, Sep 19, 2012 at 1:49 PM, Laurentiu Palcu
>>>>>>> <laurentiu.palcu@intel.com> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> It's been quite a long time since I sent the first version of postinstall
>>>>>>>> improvements which, after some debate, we decided it needed run-once
>>>>>>>> support of postinst scriptlets on host. This patcheset (RFC actually) adds
>>>>>>>> that.
>>>>>>>>
>>>>>>>> So, in order to achieve this goal I took advantage of
>>>>>>>> ROOTFS_POSTPROCESS_COMMAND variable. Basically, if running some postinst
>>>>>>>> scriptlets is time consuming (even on host) and execute repeatedly,
>>>>>>>> then we can postpone the running and run the scriplet just once. The idea is
>>>>>>>> to put the scriptlet in the ${WORKDIR}/intercept_scripts directory. When the
>>>>>>>> ROOTFS_POSTPROCESS_COMMAND is executed, it will pick up all the scripts in
>>>>>>>> this directory and execute them.
>>>>>>>>
>>>>>>>> This actual patchset does the above for the gtk icon cache generation which
>>>>>>>> takes a very long time to run on target and even on some hosts.
>>>>>>>>
>>>>>>>> The people willing to give this patchset a test, are most than welcome. Also,
>>>>>>>> please feel free to review.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Laurentiu
>>>>>>>>
>>>>>>> Thanks for taking care. I will give it a test tonight and hope to have
>>>>>>> results tomorrow.
>>>>>> It would be great if you could give it a try and let me know your results.
>>>>>>
>>>>> I removed gtk-native append in meta-oe, build from scratch and tested
>>>>> the image. No issues so far - seems you have done a great job -
>>>>> Thanks!
>>>>>
>>>> Aargh I really would like to consider this done but I found suspicious
>>>> when browsing on the machine with the new image (hicolor- and
>>>> gnome-icon-theme installed):
>>>>
>>>> * in the folder /usr/share/icons/gnome *no* icon-theme.cache is found
>>>> * /usr/share/icons/hicolor/icon-theme.cache is there but it has the
>>>> date of 01.01.2000 (have no rtc backup on the machine). I would expect
>>>> this file to have build host's date.
>>>>
>>>> So I checked the contents on the build machine in image's rootfs:
>>>>
>>>> * in the folder /usr/share/icons/gnome *no* icon-theme.cache is found
>>>> * /usr/share/icons/hicolor/icon-theme.cache is there but has only
>>>> 64,5KB (the version on the machine is 2,3MB!!).
>>> Did you have any chance to debug the issue on your setup? I tried to
>>> replicate your environment but I failed. Lots of build errors, so I gave
>>> up. It would have taken me more time to make your setup work than
>>> debugging the real problem.
>>>
>>> Another alternative would be for you to prepare a tarball with all the
>>> repos and configs that you use and put it somewhere where I can take it.
>>> It would be easier for me to directly start debugging your issue.
>>>
>> Sorry but I am occupied by other issues at the moment. Hope to find
>> time at the weekend to add some debug messages to see what's going on.
>>
> Oh it's that simple: run_intercept_scriptlets is not called here (I
> don't know what caused 'mini hicolor-icon-theme's cache)! You can
> reproduce that e.g. by enabling buildhistory.
>
> I simply replaced in image.bbclass
>
> ROOTFS_POSTPROCESS_COMMAND ?= "run_intercept_scriptlets"
> by
> ROOTFS_POSTPROCESS_COMMAND =+ "run_intercept_scriptlets;"
>
> an now see larger caches for all my icon themes. But the sizes are
> still different from those mentioned above. Will run-test tomorrow.
>
> Andreas
Hey Laurentiu,

With the minor change mentioned above I tested all my working images
without issues. Thanks for taking care and speeding up first boot.

Andreas

Re: [RFC 0/7] Postinstall improvements

[Laurentiu Palcu]

On 10/04/2012 10:16 PM, Andreas Müller wrote:
> On Thu, Oct 4, 2012 at 1:37 AM, Andreas Müller
> <schnitzeltony@googlemail.com> wrote:
>> On Wed, Sep 26, 2012 at 9:41 AM, Andreas Müller
>> <schnitzeltony@googlemail.com> wrote:
>>> On Wed, Sep 26, 2012 at 9:09 AM, Laurentiu Palcu
>>> <laurentiu.palcu@intel.com> wrote:
>>>>
>>>>
>>>> On 09/20/2012 07:12 PM, Andreas Müller wrote:
>>>>> On Thu, Sep 20, 2012 at 5:38 PM, Andreas Müller
>>>>> <schnitzeltony@googlemail.com> wrote:
>>>>>> On Wed, Sep 19, 2012 at 5:33 PM, Laurentiu Palcu
>>>>>> <laurentiu.palcu@intel.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 09/19/2012 04:41 PM, Andreas Müller wrote:
>>>>>>>> On Wed, Sep 19, 2012 at 1:49 PM, Laurentiu Palcu
>>>>>>>> <laurentiu.palcu@intel.com> wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> It's been quite a long time since I sent the first version of postinstall
>>>>>>>>> improvements which, after some debate, we decided it needed run-once
>>>>>>>>> support of postinst scriptlets on host. This patcheset (RFC actually) adds
>>>>>>>>> that.
>>>>>>>>>
>>>>>>>>> So, in order to achieve this goal I took advantage of
>>>>>>>>> ROOTFS_POSTPROCESS_COMMAND variable. Basically, if running some postinst
>>>>>>>>> scriptlets is time consuming (even on host) and execute repeatedly,
>>>>>>>>> then we can postpone the running and run the scriplet just once. The idea is
>>>>>>>>> to put the scriptlet in the ${WORKDIR}/intercept_scripts directory. When the
>>>>>>>>> ROOTFS_POSTPROCESS_COMMAND is executed, it will pick up all the scripts in
>>>>>>>>> this directory and execute them.
>>>>>>>>>
>>>>>>>>> This actual patchset does the above for the gtk icon cache generation which
>>>>>>>>> takes a very long time to run on target and even on some hosts.
>>>>>>>>>
>>>>>>>>> The people willing to give this patchset a test, are most than welcome. Also,
>>>>>>>>> please feel free to review.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Laurentiu
>>>>>>>>>
>>>>>>>> Thanks for taking care. I will give it a test tonight and hope to have
>>>>>>>> results tomorrow.
>>>>>>> It would be great if you could give it a try and let me know your results.
>>>>>>>
>>>>>> I removed gtk-native append in meta-oe, build from scratch and tested
>>>>>> the image. No issues so far - seems you have done a great job -
>>>>>> Thanks!
>>>>>>
>>>>> Aargh I really would like to consider this done but I found suspicious
>>>>> when browsing on the machine with the new image (hicolor- and
>>>>> gnome-icon-theme installed):
>>>>>
>>>>> * in the folder /usr/share/icons/gnome *no* icon-theme.cache is found
>>>>> * /usr/share/icons/hicolor/icon-theme.cache is there but it has the
>>>>> date of 01.01.2000 (have no rtc backup on the machine). I would expect
>>>>> this file to have build host's date.
>>>>>
>>>>> So I checked the contents on the build machine in image's rootfs:
>>>>>
>>>>> * in the folder /usr/share/icons/gnome *no* icon-theme.cache is found
>>>>> * /usr/share/icons/hicolor/icon-theme.cache is there but has only
>>>>> 64,5KB (the version on the machine is 2,3MB!!).
>>>> Did you have any chance to debug the issue on your setup? I tried to
>>>> replicate your environment but I failed. Lots of build errors, so I gave
>>>> up. It would have taken me more time to make your setup work than
>>>> debugging the real problem.
>>>>
>>>> Another alternative would be for you to prepare a tarball with all the
>>>> repos and configs that you use and put it somewhere where I can take it.
>>>> It would be easier for me to directly start debugging your issue.
>>>>
>>> Sorry but I am occupied by other issues at the moment. Hope to find
>>> time at the weekend to add some debug messages to see what's going on.
>>>
>> Oh it's that simple: run_intercept_scriptlets is not called here (I
>> don't know what caused 'mini hicolor-icon-theme's cache)! You can
>> reproduce that e.g. by enabling buildhistory.
>>
>> I simply replaced in image.bbclass
>>
>> ROOTFS_POSTPROCESS_COMMAND ?= "run_intercept_scriptlets"
>> by
>> ROOTFS_POSTPROCESS_COMMAND =+ "run_intercept_scriptlets;"
>>
>> an now see larger caches for all my icon themes. But the sizes are
>> still different from those mentioned above. Will run-test tomorrow.
>>
>> Andreas
> Hey Laurentiu,
> 
> With the minor change mentioned above I tested all my working images
> without issues. Thanks for taking care and speeding up first boot.

Thanks Andreas for your help with the tests and for finding the issue.
Unfortunately the patches will not be able to get into 1.3 (we're a
little late for that). I'll prepare another patch-set as soon as I'll
find some spare time and, hopefully, we'll get the patches in for 1.4.

Thanks,
Laurentiu

> 
> Andreas
> 

Re: [RFC 0/7] Postinstall improvements

[Andreas Müller]

On Fri, Oct 5, 2012 at 8:39 AM, Laurentiu Palcu
<laurentiu.palcu@intel.com> wrote:
>>>
>>> ROOTFS_POSTPROCESS_COMMAND ?= "run_intercept_scriptlets"
>>> by
>>> ROOTFS_POSTPROCESS_COMMAND =+ "run_intercept_scriptlets;"
>>>
>>> an now see larger caches for all my icon themes. But the sizes are
>>> still different from those mentioned above. Will run-test tomorrow.
>>>
>>> Andreas
>> Hey Laurentiu,
>>
>> With the minor change mentioned above I tested all my working images
>> without issues. Thanks for taking care and speeding up first boot.
>
> Thanks Andreas for your help with the tests and for finding the issue.
> Unfortunately the patches will not be able to get into 1.3 (we're a
> little late for that). I'll prepare another patch-set as soon as I'll
> find some spare time and, hopefully, we'll get the patches in for 1.4.
>
> Thanks,
> Laurentiu
>
>>
>> Andreas
>>
Although I would like to get this in I agree. Meanwhile I will put the
modified patches in on one of my build machines to get further
experience with them.

Andreas