Postinstall improvements
cover Postinstall improvements
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(-)
Signature · 1 line
1.7.9.5
RFC 1/7 gtk+: enable gtk+-native
This is needed in order to run postinst scriplets at do_rootfs time rather than first boot time.
--- 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
@@ -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
RFC 2/7 image.bbclass: run postinst scripts once, at rootfs time
In reply to Laurentiu PalcuThis 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.
--- meta/classes/image.bbclass | 24 +++++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-)
meta/classes/image.bbclass +23 -1
@@ -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
Signature · 1 line
1.7.9.5
Re: [RFC 2/7] image.bbclass: run postinst scripts once, at rootfs time
Quoted 1 line · Laurentiu Palcu
+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
Quoted 4 lines · Ross
Quoted 1 line · Laurentiu Palcu
+ROOTFS_POSTPROCESS_COMMAND ?= "
run_intercept_scriptlets"From other examples, it looks like this should be "
run_intercept_scriptlets;"
Will do. My bad.
Quoted 6 lines
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
Quoted 3 lines
Ross
Re: [RFC 2/7] image.bbclass: run postinst scripts once, at rootfs time
Quoted 5 lines · Laurentiu Palcu
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
Quoted 7 lines · Ross
Quoted 5 lines · Laurentiu Palcu
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?
Quoted 5 lines
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
Quoted 3 lines
Ross
Re: [RFC 2/7] image.bbclass: run postinst scripts once, at rootfs time
In reply to Laurentiu PalcuQuoted 46 lines · Laurentiu Palcu
This patch will allow the repeating postinst scriptlets to be run only once, on host, at
do_rootfstime. 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 <[email protected]>--- meta/classes/image.bbclass | 24 +++++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-)meta/classes/image.bbclass +16
-1@@ -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
meta/classes/image.bbclass fakeroot do_rootfs () { · line 225
Quoted 9 lines
meta/classes/image.bbclass +6
-0@@ -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
In reply to Laurentiu PalcuIn 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.
--- meta/classes/package_rpm.bbclass | 2 ++ meta/classes/rootfs_deb.bbclass | 2 ++ meta/classes/rootfs_ipk.bbclass | 2 ++ 3 files changed, 6 insertions(+)
meta/classes/package_rpm.bbclass +2 -0
@@ -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
meta/classes/rootfs_deb.bbclass +2 -0
@@ -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
meta/classes/rootfs_ipk.bbclass +2 -0
@@ -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
Signature · 1 line
1.7.9.5
RFC 4/7 gtk-icon-cache: run the icon generation at rootfs time
In reply to Laurentiu PalcuThis 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.
--- meta/classes/gtk-icon-cache.bbclass | 21 +++++++++++++++++---- 1 file changed, 17 insertions(+), 4 deletions(-)
meta/classes/gtk-icon-cache.bbclass +17 -4
@@ -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() {
Signature · 1 line
1.7.9.5
Re: [RFC 4/7] gtk-icon-cache: run the icon generation at rootfs time
Quoted 19 lines · 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 <[email protected]>--- meta/classes/gtk-icon-cache.bbclass | 21 +++++++++++++++++---- 1 file changed, 17 insertions(+), 4 deletions(-)meta/classes/gtk-icon-cache.bbclass +0
-1@@ -1,12 +1,24 @@ FILES_${PN} += "${datadir}/icons/hicolor" -DEPENDS += "${@['hicolor-icon-theme', '']['${BPN}' == 'hicolor-icon-theme']}"
meta/classes/gtk-icon-cache.bbclass line 9
Quoted 10 lines
meta/classes/gtk-icon-cache.bbclass +4
-3+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.
Quoted 31 lines
meta/classes/gtk-icon-cache.bbclass +13
-1+ +# 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
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [RFC 4/7] gtk-icon-cache: run the icon generation at rootfs time
Quoted 2 lines · Khem Raj
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
Quoted 6 lines · Ross
Quoted 2 lines · Khem Raj
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/bashand no dependency on bash... probably should make that sh-compliant.
Will do.
Thanks,
Laurentiu
Quoted 3 lines
Ross
RFC 5/7 gdk-pixbuf: generate the pixbuf loader's cache ar rootfs time
In reply to Laurentiu PalcuThis will generate the loaders.cache file for pixbuf, at rootfs time.
--- meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.24.1.bb | 24 ++++++++++++-------- 1 file changed, 14 insertions(+), 10 deletions(-)
meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.24.1.bb +14 -10
@@ -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-*"
Signature · 1 line
1.7.9.5
Re: [RFC 5/7] gdk-pixbuf: generate the pixbuf loader's cache ar rootfs time
Quoted 17 lines · Laurentiu Palcu
This will generate the loaders.cache file for pixbuf, at rootfs time.
Signed-off-by Laurentiu Palcu <[email protected]>--- meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.24.1.bb | 24 ++++++++++++-------- 1 file changed, 14 insertions(+), 10 deletions(-)meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.24.1.bb +1
-1@@ -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
meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.24.1.bb FILES_${PN}-dbg += " \ · line 70
Quoted 10 lines
meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.24.1.bb +10
-0+# 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 ?
Quoted 25 lines
meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.24.1.bb +3
-10+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
[email protected]
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
Quoted 26 lines · Khem Raj
Quoted 24 lines · Laurentiu Palcu
This will generate the loaders.cache file for pixbuf, at rootfs time.
Signed-off-by Laurentiu Palcu <[email protected]>--- meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.24.1.bb | 24 ++++++++++++-------- 1 file changed, 14 insertions(+), 10 deletions(-)meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.24.1.bb +8
-1@@ -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
Quoted 8 lines
meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.24.1.bb FILES_${PN}-dbg += " \ · line 70
Quoted 3 lines
meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.24.1.bb +3
-0+ +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
Quoted 26 lines
Quoted 26 lines
meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.24.1.bb +3
-10+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
[email protected]
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
In reply to Laurentiu PalcuThis patch is for reusing the postint scriptlet of the gtk-icon-cache.bbclass.
--- .../sato-icon-theme/sato-icon-theme.inc | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-)
meta/recipes-sato/sato-icon-theme/sato-icon-theme.inc +7 -6
@@ -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 }
Signature · 1 line
1.7.9.5
Re: [RFC 6/7] sato-icon-theme: make use of the gtk-icon-cache postinst scriptlet
meta/recipes-sato/sato-icon-theme/sato-icon-theme.inc LICENSE = "CC-BY-SA-3.0" · line 9
Quoted 3 lines · Laurentiu Palcu
SECTION = "x11"
meta/recipes-sato/sato-icon-theme/sato-icon-theme.inc +1
-1-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
Quoted 7 lines · Ross
meta/recipes-sato/sato-icon-theme/sato-icon-theme.inc LICENSE = "CC-BY-SA-3.0" · line 9
Quoted 3 lines · Laurentiu Palcu
SECTION = "x11"
meta/recipes-sato/sato-icon-theme/sato-icon-theme.inc +1
-1-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
Quoted 3 lines
Ross
RFC 7/7 postinst changes: bump PR to all recipes inheriting gnome and gtk-icon-cache
In reply to Laurentiu Palcu--- .../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(-)
meta/recipes-connectivity/connman/connman-gnome_0.7.bb +2 -0
@@ -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
meta/recipes-gnome/gnome/gnome-common_2.28.0.bb +1 -1
@@ -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
meta/recipes-gnome/gnome/gnome-desktop.inc +1 -1
@@ -11,7 +11,7 @@ do_configure_prepend () { FILES_${PN} += "${datadir}/gnome-about ${datadir}/libgnome-desktop/pnp.ids" -PR = "r6" +PR = "r7" inherit gnome pkgconfig
meta/recipes-gnome/gnome/gnome-doc-utils_0.20.6.bb +1 -1
@@ -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 \
meta/recipes-gnome/gnome/gnome-keyring_2.32.1.bb +1 -1
@@ -11,7 +11,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \ SECTION = "x11/gnome" -PR = "r8" +PR = "r9" inherit autotools gnome gtk-doc pkgconfig
meta/recipes-gnome/gnome/gnome-mime-data_2.18.0.bb +1 -1
@@ -8,7 +8,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=59530bdf33659b29e73d4adb9f9f6552 \ inherit gnome inherit autotools -PR = "r4" +PR = "r5" SRC_URI += "file://pkgconfig.patch"
meta/recipes-gnome/gnome/libgdata_0.7.1.bb +2 -0
@@ -13,3 +13,5 @@ inherit gnome pkgconfig autotools gettext SRC_URI[archive.md5sum] = "ec5262cbcb07b63b58d45aa3ac636096" SRC_URI[archive.sha256sum] = "fb244138276a5ce98510b0e2408bbf6f9ce0fd8cdcf86f07cd4be38afbb7c2bc" + +PR = "r1"
meta/recipes-gnome/gnome/libgnome-keyring_2.32.0.bb +1 -1
@@ -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
meta/recipes-gnome/gnome/metacity_2.30.3.bb +1 -1
@@ -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
meta/recipes-gnome/gthumb/gthumb_2.12.4.bb +1 -1
@@ -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"
meta/recipes-gnome/gtk-engines/gtk-engines_2.20.2.bb +1 -1
@@ -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-*"
meta/recipes-gnome/hicolor-icon-theme/hicolor-icon-theme_0.12.bb +1 -1
@@ -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"
meta/recipes-gnome/json-glib/json-glib_0.14.2.bb +1 -1
@@ -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"
meta/recipes-gnome/libglade/libglade_2.6.4.bb +1 -1
@@ -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
meta/recipes-gnome/librsvg/librsvg_2.32.1.bb +1 -1
@@ -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
meta/recipes-graphics/mutter/mutter_2.29.1.bb +1 -1
@@ -1,6 +1,6 @@ require mutter.inc -PR = "r1" +PR = "r2" LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f"
meta/recipes-graphics/mutter/mutter_git.bb +1 -1
@@ -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"
meta/recipes-sato/sato-icon-theme/sato-icon-theme_0.4.1.bb +1 -1
@@ -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 \
meta/recipes-support/consolekit/consolekit_0.4.5.bb +1 -1
@@ -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 \
meta/recipes-support/libcroco/libcroco_0.6.3.bb +1 -1
@@ -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
meta/recipes-support/vte/vte_0.28.2.bb +1 -1
@@ -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"
Signature · 1 line
1.7.9.5
A message that is not in the archive (sent off-list or not yet received): CALbNGRTCyvfZFYHx6bKV8oVDJWH3X0tj1DHSJm9CkvT4xY2f7A@mail.gmail.com
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 26 lines · Laurentiu Palcu
Quoted 23 lines · Andreas Müller
Quoted 21 lines · 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_COMMANDvariable. 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 theROOTFS_POSTPROCESS_COMMANDis 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.
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
Thanks,
LaurentiuThanks 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
Quoted 31 lines · Andreas Müller
Quoted 29 lines · Laurentiu Palcu
Quoted 26 lines · Andreas Müller
Quoted 24 lines · 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_COMMANDvariable. 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 theROOTFS_POSTPROCESS_COMMANDis 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
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
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
Quoted 30 lines · Andreas Müller
Quoted 28 lines · Andreas Müller
Quoted 26 lines · Laurentiu Palcu
Quoted 23 lines · Andreas Müller
Quoted 21 lines · 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_COMMANDvariable. 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 theROOTFS_POSTPROCESS_COMMANDis 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.
Quoted 8 lines
Quoted 8 lines
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
Thanks,
LaurentiuThanks 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?
Quoted 6 lines
Quoted 3 lines
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?
Quoted 9 lines
* in the folder
/usr/share/icons/gnome*no* icon-theme.cache is found
*/usr/share/icons/hicolor/icon-theme.cacheis 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.
Quoted 2 lines
*
/usr/share/icons/hicolor/icon-theme.cacheis 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.
Quoted 9 lines
Andreas
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Quoted 36 lines · Laurentiu Palcu
Quoted 33 lines · Andreas Müller
Quoted 31 lines · Andreas Müller
Quoted 29 lines · Laurentiu Palcu
Quoted 26 lines · Andreas Müller
Quoted 24 lines · 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_COMMANDvariable. 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 theROOTFS_POSTPROCESS_COMMANDis 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
Quoted 6 lines
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
Quoted 2 lines
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,
Quoted 45 lines
Quoted 7 lines
Quoted 4 lines
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?
Quoted 9 lines
* in the folder
/usr/share/icons/gnome*no* icon-theme.cache is found
*/usr/share/icons/hicolor/icon-theme.cacheis 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 foundThat'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.
Quoted 2 lines
*
/usr/share/icons/hicolor/icon-theme.cacheis 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.
Quoted 9 lines
Andreas
_______________________________________________
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
Signature · 1 line
Martin 'JaMa' Jansa jabber: [email protected]
Quoted 50 lines · Andreas Müller
Quoted 31 lines · Andreas Müller
Quoted 29 lines · Laurentiu Palcu
Quoted 26 lines · Andreas Müller
Quoted 24 lines · 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_COMMANDvariable. 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 theROOTFS_POSTPROCESS_COMMANDis 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,
LaurentiuQuoted 8 lines
Quoted 4 lines
Quoted 2 lines
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.cacheis 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.
Quoted 5 lines
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.cacheis 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
Quoted 9 lines
Andreas
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Quoted 58 lines · Laurentiu Palcu
Quoted 50 lines · Andreas Müller
Quoted 31 lines · Andreas Müller
Quoted 29 lines · Laurentiu Palcu
Quoted 26 lines · Andreas Müller
Quoted 24 lines · 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_COMMANDvariable. 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 theROOTFS_POSTPROCESS_COMMANDis 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,
LaurentiuQuoted 8 lines
Quoted 4 lines
Quoted 2 lines
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.cacheis 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.Quoted 5 lines
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.cacheis there but has only 64,5KB (the version on the machine is 2,3MB!!).
Quoted 9 lines
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
Quoted 65 lines · Andreas Müller
Quoted 63 lines · Laurentiu Palcu
Quoted 50 lines · Andreas Müller
Quoted 31 lines · Andreas Müller
Quoted 29 lines · Laurentiu Palcu
Quoted 26 lines · Andreas Müller
Quoted 24 lines · 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_COMMANDvariable. 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 theROOTFS_POSTPROCESS_COMMANDis 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,
LaurentiuQuoted 8 lines
Quoted 4 lines
Quoted 2 lines
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.cacheis 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.Quoted 5 lines
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.cacheis 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.
Quoted 7 lines
Quoted 4 lines
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" byROOTFS_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
Quoted 80 lines · Andreas Müller
Quoted 65 lines · Andreas Müller
Quoted 63 lines · Laurentiu Palcu
Quoted 50 lines · Andreas Müller
Quoted 31 lines · Andreas Müller
Quoted 29 lines · Laurentiu Palcu
Quoted 26 lines · Andreas Müller
Quoted 24 lines · 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_COMMANDvariable. 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 theROOTFS_POSTPROCESS_COMMANDis 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,
LaurentiuQuoted 8 lines
Quoted 4 lines
Quoted 2 lines
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.cacheis 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.Quoted 5 lines
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.cacheis 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.
Quoted 7 lines
Quoted 4 lines
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_scriptletsis 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
Quoted 8 lines
ROOTFS_POSTPROCESS_COMMAND?= "run_intercept_scriptlets" byROOTFS_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
Quoted 86 lines · Andreas Müller
Quoted 84 lines · Andreas Müller
Quoted 65 lines · Andreas Müller
Quoted 63 lines · Laurentiu Palcu
Quoted 50 lines · Andreas Müller
Quoted 31 lines · Andreas Müller
Quoted 29 lines · Laurentiu Palcu
Quoted 26 lines · Andreas Müller
Quoted 24 lines · 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_COMMANDvariable. 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 theROOTFS_POSTPROCESS_COMMANDis 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,
LaurentiuQuoted 8 lines
Quoted 4 lines
Quoted 2 lines
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.cacheis 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.Quoted 5 lines
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.cacheis 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.
Quoted 7 lines
Quoted 4 lines
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_scriptletsis 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" byROOTFS_POSTPROCESS_COMMAND=+ "run_intercept_scriptlets;"
Quoted 8 lines
Quoted 4 lines
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
Quoted 3 lines
Andreas
Quoted 14 lines · Laurentiu Palcu
Quoted 5 lines
Quoted 5 lines
ROOTFS_POSTPROCESS_COMMAND?= "run_intercept_scriptlets" byROOTFS_POSTPROCESS_COMMAND=+ "run_intercept_scriptlets;"Quoted 8 lines
Quoted 4 lines
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.
Quoted 11 lines
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,
LaurentiuQuoted 3 lines
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