| Submitter | Laurentiu Palcu |
|---|---|
| Date | Aug. 5, 2012, 4:58 p.m. |
| Message ID | <501EA63F.9090304@intel.com> |
| Download | mbox | patch |
| Permalink | /patch/33901/ |
| State | New |
| Headers | show |
Comments
On Sun, Aug 5, 2012 at 6:58 PM, Laurentiu Palcu <laurentiu.palcu@intel.com> wrote: > You could give it a test yourselves and let me know your results. I will > send a version 2 of the patchset(as soon as we all agree on the > solution), with some changes suggested by Mark and some PR bumps > suggested by Koen. With the image I usually work with [1] and AMD Phenom II X6 1090 16GB RAM I get a measurable delay - see attachment. I would not be happy loosing latest do_rootfs enhancements (off topic - thanks for that). Remeber we are only talking of gtk-update-icon-cache. OK I could buy an intel host and work just with sato images but... Andreas [1] https://gitorious.org/schnitzeltony-oe-meta/meta-misc/blobs/master/recipes-image/xfce-full-image.bb
On Mon, Aug 6, 2012 at 12:30 AM, Andreas Müller <schnitzeltony@googlemail.com> wrote: > On Sun, Aug 5, 2012 at 6:58 PM, Laurentiu Palcu > <laurentiu.palcu@intel.com> wrote: >> You could give it a test yourselves and let me know your results. I will >> send a version 2 of the patchset(as soon as we all agree on the >> solution), with some changes suggested by Mark and some PR bumps >> suggested by Koen. > With the image I usually work with [1] and AMD Phenom II X6 1090 16GB > RAM I get a measurable delay - see attachment. I would not be happy > loosing latest do_rootfs enhancements (off topic - thanks for that). > Remeber we are only talking of gtk-update-icon-cache. OK I could buy > an intel host and work just with sato images but... > > Andreas > > [1] https://gitorious.org/schnitzeltony-oe-meta/meta-misc/blobs/master/recipes-image/xfce-full-image.bb OK I know it is not that important: The image created with this patch series creates tons of messages like xfdesktop:446): GdkPixbuf-WARNING **: Cannot open pixbuf loader module file '/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache': No such file or directory and don't have icons at all. Did you run test that (on a hardware plattform different to your host)? Andreas
On 08/06/2012 01:49 AM, Andreas Müller wrote: > On Mon, Aug 6, 2012 at 12:30 AM, Andreas Müller > <schnitzeltony@googlemail.com> wrote: >> On Sun, Aug 5, 2012 at 6:58 PM, Laurentiu Palcu >> <laurentiu.palcu@intel.com> wrote: >>> You could give it a test yourselves and let me know your results. I will >>> send a version 2 of the patchset(as soon as we all agree on the >>> solution), with some changes suggested by Mark and some PR bumps >>> suggested by Koen. >> With the image I usually work with [1] and AMD Phenom II X6 1090 16GB >> RAM I get a measurable delay - see attachment. I would not be happy >> loosing latest do_rootfs enhancements (off topic - thanks for that). >> Remeber we are only talking of gtk-update-icon-cache. OK I could buy >> an intel host and work just with sato images but... I suppose you could, but nobody asked you to do that, it's your choice what's your build machine or what you'll be building for. Thanks for the measurements though. They do, indeed, show quite a significant amount of time (around 6 minutes). A run-once solution is to be considered in this case. >> >> Andreas >> >> [1] https://gitorious.org/schnitzeltony-oe-meta/meta-misc/blobs/master/recipes-image/xfce-full-image.bb > OK I know it is not that important: The image created with this patch > series creates tons of messages like Why do you think is not important. Please elaborate. Or is it irony? I don't think is in anybody's benefit if you take this approach. :) All errors/warnings are important and they have to be taken care of. > > xfdesktop:446): GdkPixbuf-WARNING **: Cannot open pixbuf loader module > file '/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache': No such file or > directory > > and don't have icons at all. Did you run test that (on a hardware > plattform different to your host)? I only tested on qemu. And it worked just fine, without any errors. With all icons in place. > > Andreas > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core >
On Mon, Aug 6, 2012 at 9:48 AM, Laurentiu Palcu <laurentiu.palcu@intel.com> wrote: > > > On 08/06/2012 01:49 AM, Andreas Müller wrote: >> On Mon, Aug 6, 2012 at 12:30 AM, Andreas Müller >> <schnitzeltony@googlemail.com> wrote: >>> On Sun, Aug 5, 2012 at 6:58 PM, Laurentiu Palcu >>> <laurentiu.palcu@intel.com> wrote: >>>> You could give it a test yourselves and let me know your results. I will >>>> send a version 2 of the patchset(as soon as we all agree on the >>>> solution), with some changes suggested by Mark and some PR bumps >>>> suggested by Koen. >>> With the image I usually work with [1] and AMD Phenom II X6 1090 16GB >>> RAM I get a measurable delay - see attachment. I would not be happy >>> loosing latest do_rootfs enhancements (off topic - thanks for that). >>> Remeber we are only talking of gtk-update-icon-cache. OK I could buy >>> an intel host and work just with sato images but... > I suppose you could, but nobody asked you to do that, it's your choice > what's your build machine or what you'll be building for. > > Thanks for the measurements though. They do, indeed, show quite a > significant amount of time (around 6 minutes). A run-once solution is to > be considered in this case. > >>> >>> Andreas >>> >>> [1] https://gitorious.org/schnitzeltony-oe-meta/meta-misc/blobs/master/recipes-image/xfce-full-image.bb >> OK I know it is not that important: The image created with this patch >> series creates tons of messages like > Why do you think is not important. Please elaborate. Or is it irony? Yes sorry - it was late night. > I don't think is in anybody's benefit if you take this approach. :) All > errors/warnings are important and they have to be taken care of. > >> >> xfdesktop:446): GdkPixbuf-WARNING **: Cannot open pixbuf loader module >> file '/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache': No such file or >> directory >> >> and don't have icons at all. Did you run test that (on a hardware >> plattform different to your host)? > I only tested on qemu. And it worked just fine, without any errors. With > all icons in place. Which hardware did you emulate? My tests were done for overo (ARM cortext A8). I wonder if the created database is machine specific. Andreas
On 08/06/2012 11:10 AM, Andreas Müller wrote: > On Mon, Aug 6, 2012 at 9:48 AM, Laurentiu Palcu > <laurentiu.palcu@intel.com> wrote: >> >> >> On 08/06/2012 01:49 AM, Andreas Müller wrote: >>> On Mon, Aug 6, 2012 at 12:30 AM, Andreas Müller >>> <schnitzeltony@googlemail.com> wrote: >>>> On Sun, Aug 5, 2012 at 6:58 PM, Laurentiu Palcu >>>> <laurentiu.palcu@intel.com> wrote: >>>>> You could give it a test yourselves and let me know your results. I will >>>>> send a version 2 of the patchset(as soon as we all agree on the >>>>> solution), with some changes suggested by Mark and some PR bumps >>>>> suggested by Koen. >>>> With the image I usually work with [1] and AMD Phenom II X6 1090 16GB >>>> RAM I get a measurable delay - see attachment. I would not be happy >>>> loosing latest do_rootfs enhancements (off topic - thanks for that). >>>> Remeber we are only talking of gtk-update-icon-cache. OK I could buy >>>> an intel host and work just with sato images but... >> I suppose you could, but nobody asked you to do that, it's your choice >> what's your build machine or what you'll be building for. >> >> Thanks for the measurements though. They do, indeed, show quite a >> significant amount of time (around 6 minutes). A run-once solution is to >> be considered in this case. >> >>>> >>>> Andreas >>>> >>>> [1] https://gitorious.org/schnitzeltony-oe-meta/meta-misc/blobs/master/recipes-image/xfce-full-image.bb >>> OK I know it is not that important: The image created with this patch >>> series creates tons of messages like >> Why do you think is not important. Please elaborate. Or is it irony? > Yes sorry - it was late night. It's OK, let's work together and find the best solution for all of us. I would also be pissed of if I had to wait an extra 6 minutes every do_rootfs run. >> I don't think is in anybody's benefit if you take this approach. :) All >> errors/warnings are important and they have to be taken care of. >> >>> >>> xfdesktop:446): GdkPixbuf-WARNING **: Cannot open pixbuf loader module >>> file '/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache': No such file or >>> directory >>> >>> and don't have icons at all. Did you run test that (on a hardware >>> plattform different to your host)? >> I only tested on qemu. And it worked just fine, without any errors. With >> all icons in place. > Which hardware did you emulate? My tests were done for overo (ARM > cortext A8). I wonder if the created database is machine specific. I used qemuarm. As far as I know, the database shouldn't be machine specific. And, looking at the log you sent, it looks like all commands succeeded. Otherwise, the 'time' application would also signal in the log file if the command failed. Could please have a look, on your host (xfce-full-image-1.0-r0/rootfs/usr/share/icons/hicolor or xfce-full-image-1.0-r0/rootfs/usr/share/icons/gnome), to see if it creates the icon-theme.cache files? It does for me and I don't understand why it doesn't in your case... Thanks, Laurentiu > > Andreas > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core >
On 6 August 2012 10:18, Laurentiu Palcu <laurentiu.palcu@intel.com> wrote: >> Which hardware did you emulate? My tests were done for overo (ARM >> cortext A8). I wonder if the created database is machine specific. > I used qemuarm. As far as I know, the database shouldn't be machine > specific. Looking at updateiconcache.c, all of the functions that write data to the cache file use write_card16, write_card32 and so on which convert to big-endian. Unless there's a bug hidden away, the cache files are cross-platform. Ross
On Mon, Aug 6, 2012 at 11:18 AM, Laurentiu Palcu <laurentiu.palcu@intel.com> wrote: > > > On 08/06/2012 11:10 AM, Andreas Müller wrote: >> On Mon, Aug 6, 2012 at 9:48 AM, Laurentiu Palcu >> <laurentiu.palcu@intel.com> wrote: >>> >>> >>> On 08/06/2012 01:49 AM, Andreas Müller wrote: >>>> On Mon, Aug 6, 2012 at 12:30 AM, Andreas Müller >>>> <schnitzeltony@googlemail.com> wrote: >>>>> On Sun, Aug 5, 2012 at 6:58 PM, Laurentiu Palcu >>>>> <laurentiu.palcu@intel.com> wrote: >>>>>> You could give it a test yourselves and let me know your results. I will >>>>>> send a version 2 of the patchset(as soon as we all agree on the >>>>>> solution), with some changes suggested by Mark and some PR bumps >>>>>> suggested by Koen. >>>>> With the image I usually work with [1] and AMD Phenom II X6 1090 16GB >>>>> RAM I get a measurable delay - see attachment. I would not be happy >>>>> loosing latest do_rootfs enhancements (off topic - thanks for that). >>>>> Remeber we are only talking of gtk-update-icon-cache. OK I could buy >>>>> an intel host and work just with sato images but... >>> I suppose you could, but nobody asked you to do that, it's your choice >>> what's your build machine or what you'll be building for. >>> >>> Thanks for the measurements though. They do, indeed, show quite a >>> significant amount of time (around 6 minutes). A run-once solution is to >>> be considered in this case. >>> >>>>> >>>>> Andreas >>>>> >>>>> [1] https://gitorious.org/schnitzeltony-oe-meta/meta-misc/blobs/master/recipes-image/xfce-full-image.bb >>>> OK I know it is not that important: The image created with this patch >>>> series creates tons of messages like >>> Why do you think is not important. Please elaborate. Or is it irony? >> Yes sorry - it was late night. > It's OK, let's work together and find the best solution for all of us. I > would also be pissed of if I had to wait an extra 6 minutes every > do_rootfs run. > >>> I don't think is in anybody's benefit if you take this approach. :) All >>> errors/warnings are important and they have to be taken care of. >>> >>>> >>>> xfdesktop:446): GdkPixbuf-WARNING **: Cannot open pixbuf loader module >>>> file '/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache': No such file or >>>> directory >>>> >>>> and don't have icons at all. Did you run test that (on a hardware >>>> plattform different to your host)? >>> I only tested on qemu. And it worked just fine, without any errors. With >>> all icons in place. >> Which hardware did you emulate? My tests were done for overo (ARM >> cortext A8). I wonder if the created database is machine specific. > I used qemuarm. As far as I know, the database shouldn't be machine > specific. And, looking at the log you sent, it looks like all commands > succeeded. Otherwise, the 'time' application would also signal in the > log file if the command failed. Could please have a look, on your host > (xfce-full-image-1.0-r0/rootfs/usr/share/icons/hicolor or > xfce-full-image-1.0-r0/rootfs/usr/share/icons/gnome), to see if it > creates the icon-theme.cache files? It does for me and I don't > understand why it doesn't in your case... > I will check today evening since the machine with this data is at home... Andreas
On Mon, Aug 6, 2012 at 11:18 AM, Laurentiu Palcu <laurentiu.palcu@intel.com> wrote: > > > On 08/06/2012 11:10 AM, Andreas Müller wrote: >> On Mon, Aug 6, 2012 at 9:48 AM, Laurentiu Palcu >> <laurentiu.palcu@intel.com> wrote: >>> >>> >>> On 08/06/2012 01:49 AM, Andreas Müller wrote: >>>> On Mon, Aug 6, 2012 at 12:30 AM, Andreas Müller >>>> <schnitzeltony@googlemail.com> wrote: >>>>> On Sun, Aug 5, 2012 at 6:58 PM, Laurentiu Palcu >>>>> <laurentiu.palcu@intel.com> wrote: >>>>>> You could give it a test yourselves and let me know your results. I will >>>>>> send a version 2 of the patchset(as soon as we all agree on the >>>>>> solution), with some changes suggested by Mark and some PR bumps >>>>>> suggested by Koen. >>>>> With the image I usually work with [1] and AMD Phenom II X6 1090 16GB >>>>> RAM I get a measurable delay - see attachment. I would not be happy >>>>> loosing latest do_rootfs enhancements (off topic - thanks for that). >>>>> Remeber we are only talking of gtk-update-icon-cache. OK I could buy >>>>> an intel host and work just with sato images but... >>> I suppose you could, but nobody asked you to do that, it's your choice >>> what's your build machine or what you'll be building for. >>> >>> Thanks for the measurements though. They do, indeed, show quite a >>> significant amount of time (around 6 minutes). A run-once solution is to >>> be considered in this case. >>> >>>>> >>>>> Andreas >>>>> >>>>> [1] https://gitorious.org/schnitzeltony-oe-meta/meta-misc/blobs/master/recipes-image/xfce-full-image.bb >>>> OK I know it is not that important: The image created with this patch >>>> series creates tons of messages like >>> Why do you think is not important. Please elaborate. Or is it irony? >> Yes sorry - it was late night. > It's OK, let's work together and find the best solution for all of us. I > would also be pissed of if I had to wait an extra 6 minutes every > do_rootfs run. > >>> I don't think is in anybody's benefit if you take this approach. :) All >>> errors/warnings are important and they have to be taken care of. >>> >>>> >>>> xfdesktop:446): GdkPixbuf-WARNING **: Cannot open pixbuf loader module >>>> file '/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache': No such file or >>>> directory >>>> >>>> and don't have icons at all. Did you run test that (on a hardware >>>> plattform different to your host)? >>> I only tested on qemu. And it worked just fine, without any errors. With >>> all icons in place. >> Which hardware did you emulate? My tests were done for overo (ARM >> cortext A8). I wonder if the created database is machine specific. > I used qemuarm. As far as I know, the database shouldn't be machine > specific. And, looking at the log you sent, it looks like all commands > succeeded. Otherwise, the 'time' application would also signal in the > log file if the command failed. Could please have a look, on your host > (xfce-full-image-1.0-r0/rootfs/usr/share/icons/hicolor or > xfce-full-image-1.0-r0/rootfs/usr/share/icons/gnome), to see if it > creates the icon-theme.cache files? It does for me and I don't > understand why it doesn't in your case... > > Thanks, > Laurentiu > I checked: In both I find the files icon-theme.cache. Andreas
Patch
diff --git a/meta/recipes-gnome/gtk+/gtk+_2.24.8.bb b/meta/recipes-gnome/gtk+/gtk+_2.24.8.bb index 878eb87..e77ecce 100644 --- a/meta/recipes-gnome/gtk+/gtk+_2.24.8.bb +++ b/meta/recipes-gnome/gtk+/gtk+_2.24.8.bb @@ -41,6 +41,18 @@ BBCLASSEXTEND = "native" RRECOMMENDS_${PN}_virtclass-native = "" DEPENDS_virtclass-native = "glib-2.0-native atk-native pango-native cairo-native gdk-pixbuf-native" +do_install_append_virtclass-native () { + mv ${D}/${bindir}/gtk-update-icon-cache ${D}/${bindir}/gtk-update-icon-cache.real + + cat << "EOF" > ${D}/${bindir}/gtk-update-icon-cache +#!/bin/bash + +echo "Executing: gtk-update-icon-cache $@" >> ${TMPDIR}/do_rootfs.log +/usr/bin/time --f "real:%e user:%U sys:%S" -o ${TMPDIR}/do_rootfs.log --append gtk-update-icon-cache.real $@ +EOF + chmod +x ${D}/${bindir}/gtk-update-icon-cache +} + python populate_packages_prepend () { prologue = d.getVar("postinst_prologue", True)