Re: [OE-core] postinst does not finish
Op 18 apr. 2013, om 20:45 heeft Koen Kooi k...@dominion.thruhere.net het volgende geschreven: Op 17 apr. 2013, om 20:55 heeft Burton, Ross ross.bur...@intel.com het volgende geschreven: On 17 April 2013 19:27, Koen Kooi k...@dominion.thruhere.net wrote: I get a similar result here, but I have to rerun all postinsts with gconftool to make the packages actually work. I'll update OE-core tomorrow and try to get some more debug info. Systemctl says postinsts ran for 3 and a half minutes, a big improvement over the 60+ minutes for the same image built against 1.3. 3.5 minutes is still a long time, what packages does it run on the target? I finally have a new build done and was able to inspect log.do_rootfs: [koen@rrMBP 1.0-r0]$ grep configuration required on target temp/log.do_rootfs gdk-pixbuf-loader-png.postinst returned 1, marking as unpacked only, configuration required on target. gdk-pixbuf-loader-jpeg.postinst returned 1, marking as unpacked only, configuration required on target. liberation-fonts.postinst returned 1, marking as unpacked only, configuration required on target. gdk-pixbuf-loader-xpm.postinst returned 1, marking as unpacked only, configuration required on target. gdk-pixbuf-loader-gif.postinst returned 1, marking as unpacked only, configuration required on target. hicolor-icon-theme.postinst returned 1, marking as unpacked only, configuration required on target. gnome-bluetooth.postinst returned 1, marking as unpacked only, configuration required on target. gnome-disk-utility.postinst returned 1, marking as unpacked only, configuration required on target. nautilus.postinst returned 1, marking as unpacked only, configuration required on target. gnome-session.postinst returned 1, marking as unpacked only, configuration required on target. gdm.postinst returned 1, marking as unpacked only, configuration required on target. gnome-settings-daemon.postinst returned 1, marking as unpacked only, configuration required on target. libgweather1.postinst returned 1, marking as unpacked only, configuration required on target. gnome-panel.postinst returned 1, marking as unpacked only, configuration required on target. gnome-power-manager.postinst returned 1, marking as unpacked only, configuration required on target. gnome-control-center.postinst returned 1, marking as unpacked only, configuration required on target. epiphany.postinst returned 1, marking as unpacked only, configuration required on target. gnome-theme-crux.postinst returned 1, marking as unpacked only, configuration required on target. gnome-theme-highcontrastlargeprint.postinst returned 1, marking as unpacked only, configuration required on target. librsvg-2-gtk.postinst returned 1, marking as unpacked only, configuration required on target. ttf-liberation-sans.postinst returned 1, marking as unpacked only, configuration required on target. gnome-icon-theme.postinst returned 1, marking as unpacked only, configuration required on target. gnome-theme-highcontrastinverse.postinst returned 1, marking as unpacked only, configuration required on target. gnome-theme-mist.postinst returned 1, marking as unpacked only, configuration required on target. ttf-liberation-serif.postinst returned 1, marking as unpacked only, configuration required on target. ttf-liberation-mono.postinst returned 1, marking as unpacked only, configuration required on target. gnome-theme-largeprint.postinst returned 1, marking as unpacked only, configuration required on target. gnome-themes.postinst returned 1, marking as unpacked only, configuration required on target. udev-hwdb.postinst returned 1, marking as unpacked only, configuration required on target. gnome-theme-highcontrastlargeprintinverse.postinst returned 1, marking as unpacked only, configuration required on target. gnome-theme-highcontrast.postinst returned 1, marking as unpacked only, configuration required on target. gdk-pixbuf-loader-png.postinst returned 1, marking as unpacked only, configuration required on target. gdk-pixbuf-loader-jpeg.postinst returned 1, marking as unpacked only, configuration required on target. liberation-fonts.postinst returned 1, marking as unpacked only, configuration required on target. gdk-pixbuf-loader-xpm.postinst returned 1, marking as unpacked only, configuration required on target. gdk-pixbuf-loader-gif.postinst returned 1, marking as unpacked only, configuration required on target. hicolor-icon-theme.postinst returned 1, marking as unpacked only, configuration required on target. gnome-bluetooth.postinst returned 1, marking as unpacked only, configuration required on target. gnome-disk-utility.postinst returned 1, marking as unpacked only, configuration required on target. nautilus.postinst returned 1, marking as unpacked only, configuration required on target. gnome-session.postinst returned 1, marking as unpacked
[OE-core] [PATCH] libomxil (0.9.3): drop unecessary dependencies
Since version 0.9.2, Bellagio's components (vorbis, mad, also, ...) are shipped in separate packages. Signed-off-by: Matthieu Crapetmcra...@gmail.com --- meta/recipes-multimedia/libomxil/libomxil_0.9.3.bb | 1 - 1 file changed, 1 deletion(-) diff --git a/meta/recipes-multimedia/libomxil/libomxil_0.9.3.bb b/meta/recipes-multimedia/libomxil/libomxil_0.9.3.bb index ded0e1c..8c3166f 100644 --- a/meta/recipes-multimedia/libomxil/libomxil_0.9.3.bb +++ b/meta/recipes-multimedia/libomxil/libomxil_0.9.3.bb @@ -4,7 +4,6 @@ LICENSE = LGPLv2.1+ LICENSE_FLAGS = commercial LIC_FILES_CHKSUM = file://COPYING;md5=ae6f0f4dbc7ac193b50f323a6ae191cb \ file://src/omxcore.h;beginline=1;endline=27;md5=806b1e5566c06486fe8e42b461e03a90 -DEPENDS = libvorbis libogg alsa-lib libmad PR = r0 -- 1.8.2.1 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] postinst does not finish
On 18 April 2013 19:45, Koen Kooi k...@dominion.thruhere.net wrote: [koen@rrMBP 1.0-r0]$ grep configuration required on target temp/log.do_rootfs gdk-pixbuf-loader-png.postinst returned 1, marking as unpacked only, configuration required on target. ... This is usual for postinsts that are intercepted and handled in a single go - scroll further down the log and you should see the package manager running the intercept scripts (i.e. fontcaches once, gconftool once). I expect you'll see there that the gconftool intercept is breaking for some reason. Ross ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] postinst does not finish
On 19 April 2013 09:38, Burton, Ross ross.bur...@intel.com wrote: On 18 April 2013 19:45, Koen Kooi k...@dominion.thruhere.net wrote: [koen@rrMBP 1.0-r0]$ grep configuration required on target temp/log.do_rootfs gdk-pixbuf-loader-png.postinst returned 1, marking as unpacked only, configuration required on target. .. This is usual for postinsts that are intercepted and handled in a single go - scroll further down the log and you should see the package manager running the intercept scripts (i.e. fontcaches once, gconftool once). I expect you'll see there that the gconftool intercept is breaking for some reason. Actually gconf isn't using triggers but it should happen on the host. I wonder if we're hitting a problem where the postinsts are doing some actions on the host and then triggers are erroring out and it's all falling back to the target. Can you share the complete rootfs log for this gnome image? Ross ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] libomxil (0.9.3): drop unecessary dependencies
Since version 0.9.2, Bellagio's components (vorbis, mad, also, ...) are shipped in separate packages. Signed-off-by: Matthieu Crapet mcra...@gmail.com --- meta/recipes-multimedia/libomxil/libomxil_0.9.3.bb | 1 - 1 file changed, 1 deletion(-) diff --git a/meta/recipes-multimedia/libomxil/libomxil_0.9.3.bb b/meta/recipes-multimedia/libomxil/libomxil_0.9.3.bb index ded0e1c..8c3166f 100644 --- a/meta/recipes-multimedia/libomxil/libomxil_0.9.3.bb +++ b/meta/recipes-multimedia/libomxil/libomxil_0.9.3.bb @@ -4,7 +4,6 @@ LICENSE = LGPLv2.1+ LICENSE_FLAGS = commercial LIC_FILES_CHKSUM = file://COPYING;md5=ae6f0f4dbc7ac193b50f323a6ae191cb \ file://src/omxcore.h;beginline=1;endline=27;md5=806b1e5566c06486fe8e42b461e03a90 -DEPENDS = libvorbis libogg alsa-lib libmad PR = r0 -- 1.8.2.1 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] postinst does not finish
Op 19 apr. 2013, om 10:52 heeft Burton, Ross ross.bur...@intel.com het volgende geschreven: On 19 April 2013 09:38, Burton, Ross ross.bur...@intel.com wrote: On 18 April 2013 19:45, Koen Kooi k...@dominion.thruhere.net wrote: [koen@rrMBP 1.0-r0]$ grep configuration required on target temp/log.do_rootfs gdk-pixbuf-loader-png.postinst returned 1, marking as unpacked only, configuration required on target. .. This is usual for postinsts that are intercepted and handled in a single go - scroll further down the log and you should see the package manager running the intercept scripts (i.e. fontcaches once, gconftool once). I expect you'll see there that the gconftool intercept is breaking for some reason. Actually gconf isn't using triggers but it should happen on the host. I wonder if we're hitting a problem where the postinsts are doing some actions on the host and then triggers are erroring out and it's all falling back to the target. Can you share the complete rootfs log for this gnome image? Here's the complete log: http://dominion.thruhere.net/koen/angstrom/beaglebone/log.do_rootfs Todays build is still building :( ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] tweaking insane.bbclass to handle MIPS SEAD-3?
On Thursday 18 April 2013 13:14:51 Robert P. J. Day wrote: if one created a BSP for the MIPS SEAD-3, where would it go? i notice there's no current MIPS-related OE layer anywhere. i'm assuming http://layers.openembedded.org/layerindex/ is the canonical source these days for layer locations, yes? the only MIPS match one gets there is for the qemumips machine. I guess there isn't one yet, so if you'd like to create and publish one, go for it. There's some info on how that should be done in the OE layers FAQ: http://www.openembedded.org/Layers_FAQ Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] tweaking insane.bbclass to handle MIPS SEAD-3?
On Fri, 19 Apr 2013, Paul Eggleton wrote: On Thursday 18 April 2013 13:14:51 Robert P. J. Day wrote: if one created a BSP for the MIPS SEAD-3, where would it go? i notice there's no current MIPS-related OE layer anywhere. i'm assuming http://layers.openembedded.org/layerindex/ is the canonical source these days for layer locations, yes? the only MIPS match one gets there is for the qemumips machine. I guess there isn't one yet, so if you'd like to create and publish one, go for it. There's some info on how that should be done in the OE layers FAQ: http://www.openembedded.org/Layers_FAQ short note -- the wiki page Creating a new Layer: http://www.openembedded.org/wiki/Creating_a_new_Layer seems out of date, in that the Best practices section refers to qt4.inc and the QT_SQL_DRIVER_FLAGS variable: An example here would be the way Qt 4 database support plugins are configured - OE-core doesn't have MySQL or PostgreSQL, however meta-oe does, so meta-oe uses .bbappends to modify a variable QT_SQL_DRIVER_FLAGS to enable the appropriate plugins. This variable was added to qt4.inc in OE-core specifically to allow meta-oe to be able to control which plugins are built. i don't think so: $ git show 64c6887ca19d2ce52e538186c93163dddf68438f commit 64c6887ca19d2ce52e538186c93163dddf68438f Author: Paul Eggleton paul.eggle...@linux.intel.com Date: Wed Apr 10 15:57:59 2013 + qt4: remove bbappend content These changes to Qt's configuration need to be applied in distro layers, not in meta-oe. (We have to preserve the PRINC value to avoid PR going backwards.) Signed-off-by: Paul Eggleton paul.eggle...@linux.intel.com Signed-off-by: Martin Jansa martin.ja...@gmail.com might want to pick a different example. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] tweaking insane.bbclass to handle MIPS SEAD-3?
On Friday 19 April 2013 06:53:59 Robert P. J. Day wrote: On Fri, 19 Apr 2013, Paul Eggleton wrote: On Thursday 18 April 2013 13:14:51 Robert P. J. Day wrote: if one created a BSP for the MIPS SEAD-3, where would it go? i notice there's no current MIPS-related OE layer anywhere. i'm assuming http://layers.openembedded.org/layerindex/ is the canonical source these days for layer locations, yes? the only MIPS match one gets there is for the qemumips machine. I guess there isn't one yet, so if you'd like to create and publish one, go for it. There's some info on how that should be done in the OE layers FAQ: http://www.openembedded.org/Layers_FAQ short note -- the wiki page Creating a new Layer: http://www.openembedded.org/wiki/Creating_a_new_Layer seems out of date, in that the Best practices section refers to qt4.inc and the QT_SQL_DRIVER_FLAGS variable: An example here would be the way Qt 4 database support plugins are configured - OE-core doesn't have MySQL or PostgreSQL, however meta-oe does, so meta-oe uses .bbappends to modify a variable QT_SQL_DRIVER_FLAGS to enable the appropriate plugins. This variable was added to qt4.inc in OE-core specifically to allow meta-oe to be able to control which plugins are built. i don't think so: $ git show 64c6887ca19d2ce52e538186c93163dddf68438f commit 64c6887ca19d2ce52e538186c93163dddf68438f Author: Paul Eggleton paul.eggle...@linux.intel.com Date: Wed Apr 10 15:57:59 2013 + qt4: remove bbappend content These changes to Qt's configuration need to be applied in distro layers, not in meta-oe. (We have to preserve the PRINC value to avoid PR going backwards.) Signed-off-by: Paul Eggleton paul.eggle...@linux.intel.com Signed-off-by: Martin Jansa martin.ja...@gmail.com might want to pick a different example. Ah yes, I looked at that recently and made a mental note to change it which I then promptly forgot. It's fixed now (using the same example, but mentioning where the appends should go), thanks for pointing this out. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] postinst does not finish
On 04/19/2013 12:13 PM, Koen Kooi wrote: Op 19 apr. 2013, om 10:52 heeft Burton, Ross ross.bur...@intel.com het volgende geschreven: On 19 April 2013 09:38, Burton, Ross ross.bur...@intel.com wrote: On 18 April 2013 19:45, Koen Kooi k...@dominion.thruhere.net wrote: [koen@rrMBP 1.0-r0]$ grep configuration required on target temp/log.do_rootfs gdk-pixbuf-loader-png.postinst returned 1, marking as unpacked only, configuration required on target. .. This is usual for postinsts that are intercepted and handled in a single go - scroll further down the log and you should see the package manager running the intercept scripts (i.e. fontcaches once, gconftool once). I expect you'll see there that the gconftool intercept is breaking for some reason. Actually gconf isn't using triggers but it should happen on the host. I wonder if we're hitting a problem where the postinsts are doing some actions on the host and then triggers are erroring out and it's all falling back to the target. Can you share the complete rootfs log for this gnome image? Here's the complete log: http://dominion.thruhere.net/koen/angstrom/beaglebone/log.do_rootfs Do you think you can post the rootfs/var/lib/opkg/status file? This would show us exactly what packages were postponed for first boot. Thanks, Laurentiu Todays build is still building :( ___ 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
[OE-core] [PATCH] gconf: silence some spurious errors
The postinstalls were producing errors like this:
(gconftool-2.real:10095): GConf-WARNING **: Client failed to connect to the
D-BUS daemon:
Using X11 for dbus-daemon autolaunch was disabled at compile time, set your
DBUS_SESSION_BUS_ADDRESS instead
These are harmless but distracting, so take a patch from upstream to silence
them.
Signed-off-by: Ross Burton ross.bur...@intel.com
---
.../gnome/gconf/unable-connect-dbus.patch | 95
meta/recipes-gnome/gnome/gconf_3.2.6.bb|1 +
2 files changed, 96 insertions(+)
create mode 100644 meta/recipes-gnome/gnome/gconf/unable-connect-dbus.patch
diff --git a/meta/recipes-gnome/gnome/gconf/unable-connect-dbus.patch
b/meta/recipes-gnome/gnome/gconf/unable-connect-dbus.patch
new file mode 100644
index 000..f758a4b
--- /dev/null
+++ b/meta/recipes-gnome/gnome/gconf/unable-connect-dbus.patch
@@ -0,0 +1,95 @@
+Fixes errors such as this in the rootfs generation:
+
+(gconftool-2.real:10095): GConf-WARNING **: Client failed to connect to the
D-BUS daemon:
+Using X11 for dbus-daemon autolaunch was disabled at compile time, set your
DBUS_SESSION_BUS_ADDRESS instead
+
+Upstream-Status: Backport
+Signed-off-by: Ross Burton ross.bur...@intel.com
+
+From b0895e1998ebc83ab030ec0f17c0685439f5b404 Mon Sep 17 00:00:00 2001
+From: Ray Strode rstr...@redhat.com
+Date: Mon, 15 Apr 2013 09:57:34 -0400
+Subject: [PATCH] dbus: Don't spew to console when unable to connect to dbus
+ daemon
+
+Instead pass the error up for the caller to decide what to do.
+
+This prevent untrappable warning messages from showing up at the
+console if gconftool --makefile-install-rule is called.
+---
+ gconf/gconf-dbus.c | 24
+ 1 file changed, 12 insertions(+), 12 deletions(-)
+
+diff --git a/gconf/gconf-dbus.c b/gconf/gconf-dbus.c
+index 5610fcf..048e3ea 100644
+--- a/gconf/gconf-dbus.c
b/gconf/gconf-dbus.c
+@@ -105,7 +105,7 @@ static GHashTable *engines_by_db = NULL;
+ static GHashTable *engines_by_address = NULL;
+ static gbooleandbus_disconnected = FALSE;
+
+-static gboolean ensure_dbus_connection (void);
++static gboolean ensure_dbus_connection (GError **error);
+ static gboolean ensure_service (gboolean
start_if_not_found,
+GError **err);
+ static gboolean ensure_database (GConfEngine *conf,
+@@ -383,7 +383,7 @@ gconf_engine_detach (GConfEngine *conf)
+ }
+
+ static gboolean
+-ensure_dbus_connection (void)
++ensure_dbus_connection (GError **err)
+ {
+ DBusError error;
+
+@@ -392,7 +392,9 @@ ensure_dbus_connection (void)
+
+ if (dbus_disconnected)
+ {
+- g_warning (The connection to DBus was broken. Can't reinitialize it.);
++ g_set_error (err, GCONF_ERROR,
++ GCONF_ERROR_NO_SERVER,
++ The connection to DBus was broken. Can't reinitialize
it.);
+ return FALSE;
+ }
+
+@@ -402,7 +404,10 @@ ensure_dbus_connection (void)
+
+ if (!global_conn)
+ {
+- g_warning (Client failed to connect to the D-BUS daemon:\n%s,
error.message);
++ g_set_error (err, GCONF_ERROR,
++ GCONF_ERROR_NO_SERVER,
++ Client failed to connect to the D-BUS daemon:\n%s,
++ error.message);
+
+ dbus_error_free (error);
+ return FALSE;
+@@ -431,13 +436,8 @@ ensure_service (gboolean start_if_not_found,
+
+ if (global_conn == NULL)
+ {
+- if (!ensure_dbus_connection ())
+- {
+-g_set_error (err, GCONF_ERROR,
+- GCONF_ERROR_NO_SERVER,
+- _(No D-BUS daemon running\n));
+-return FALSE;
+- }
++ if (!ensure_dbus_connection (err))
++return FALSE;
+
+ g_assert (global_conn != NULL);
+ }
+@@ -2512,7 +2512,7 @@ gconf_ping_daemon (void)
+ {
+ if (global_conn == NULL)
+ {
+-if (!ensure_dbus_connection ())
++if (!ensure_dbus_connection (NULL))
+ {
+ return FALSE;
+ }
+--
+1.7.10.4
+
diff --git a/meta/recipes-gnome/gnome/gconf_3.2.6.bb
b/meta/recipes-gnome/gnome/gconf_3.2.6.bb
index a245fa2..a1843d5 100644
--- a/meta/recipes-gnome/gnome/gconf_3.2.6.bb
+++ b/meta/recipes-gnome/gnome/gconf_3.2.6.bb
@@ -12,6 +12,7 @@ inherit gnomebase gtk-doc
SRC_URI =
${GNOME_MIRROR}/GConf/${@gnome_verdir(${PV})}/GConf-${PV}.tar.xz;name=archive
\
file://remove_plus_from_invalid_characters_list.patch \
+ file://unable-connect-dbus.patch \
SRC_URI[archive.md5sum] = 2b16996d0e4b112856ee5c59130e822c
--
1.7.10.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] postinst does not finish
Op 19 apr. 2013, om 13:23 heeft Laurentiu Palcu laurentiu.pa...@intel.com het volgende geschreven: On 04/19/2013 12:13 PM, Koen Kooi wrote: Op 19 apr. 2013, om 10:52 heeft Burton, Ross ross.bur...@intel.com het volgende geschreven: On 19 April 2013 09:38, Burton, Ross ross.bur...@intel.com wrote: On 18 April 2013 19:45, Koen Kooi k...@dominion.thruhere.net wrote: [koen@rrMBP 1.0-r0]$ grep configuration required on target temp/log.do_rootfs gdk-pixbuf-loader-png.postinst returned 1, marking as unpacked only, configuration required on target. .. This is usual for postinsts that are intercepted and handled in a single go - scroll further down the log and you should see the package manager running the intercept scripts (i.e. fontcaches once, gconftool once). I expect you'll see there that the gconftool intercept is breaking for some reason. Actually gconf isn't using triggers but it should happen on the host. I wonder if we're hitting a problem where the postinsts are doing some actions on the host and then triggers are erroring out and it's all falling back to the target. Can you share the complete rootfs log for this gnome image? Here's the complete log: http://dominion.thruhere.net/koen/angstrom/beaglebone/log.do_rootfs Do you think you can post the rootfs/var/lib/opkg/status file? This would show us exactly what packages were postponed for first boot. This is the build that finished just before Ross sent the gconf patch: http://dominion.thruhere.net/koen/angstrom/beaglebone/Angstrom-systemd-GNOME-image-eglibc-ipk-v2013.06-beaglebone.rootfs.tar.xz (75MiB) I haven't booted that yet, I'll do that when I get back from lunch. regards, Koen Thanks, Laurentiu Todays build is still building :( ___ 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
[OE-core] [PATCH] libpng: Upgrade to 1.6.1
Signed-off-by: Emilia Ciobanu emilia.maria.silvia.ciob...@intel.com
---
...0001-configure-lower-automake-requirement.patch | 29
meta/recipes-multimedia/libpng/libpng_1.6.0.bb | 20 --
meta/recipes-multimedia/libpng/libpng_1.6.1.bb | 24
3 files changed, 53 insertions(+), 20 deletions(-)
create mode 100644
meta/recipes-multimedia/libpng/libpng/0001-configure-lower-automake-requirement.patch
delete mode 100644 meta/recipes-multimedia/libpng/libpng_1.6.0.bb
create mode 100644 meta/recipes-multimedia/libpng/libpng_1.6.1.bb
diff --git
a/meta/recipes-multimedia/libpng/libpng/0001-configure-lower-automake-requirement.patch
b/meta/recipes-multimedia/libpng/libpng/0001-configure-lower-automake-requirement.patch
new file mode 100644
index 000..34363dc
--- /dev/null
+++
b/meta/recipes-multimedia/libpng/libpng/0001-configure-lower-automake-requirement.patch
@@ -0,0 +1,29 @@
+From a4fd84bdc69e9929a1040f20ea291ee3115bf5b2 Mon Sep 17 00:00:00 2001
+From: Koen Kooi k...@dominion.thruhere.net
+Date: Mon, 15 Apr 2013 11:16:20 +0200
+Subject: [PATCH] configure: lower automake requirement
+
+We're not using parallel tests in OE-core yet
+
+Signed-off-by: Koen Kooi k...@dominion.thruhere.net
+
+Upstream-status: Inapropriate [OE specific build hack]
+---
+ configure.ac | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/configure.ac b/configure.ac
+index 1745d31..7f015fe 100644
+--- a/configure.ac
b/configure.ac
+@@ -27,7 +27,7 @@ AC_CONFIG_MACRO_DIR([scripts])
+ # dist-xz requires automake 1.11 or later
+ # 1.12.2 fixes a security issue in 1.11.2 and 1.12.1
+ # 1.13 is required for parallel tests
+-AM_INIT_AUTOMAKE([1.13 foreign dist-xz color-tests silent-rules])
++AM_INIT_AUTOMAKE([1.12.2 foreign dist-xz color-tests silent-rules])
+ # The following line causes --disable-maintainer-mode to be the default to
+ # configure, this is necessary because libpng distributions cannot rely on the
+ # time stamps of the autotools generated files being correct
+--
+1.8.1.4
diff --git a/meta/recipes-multimedia/libpng/libpng_1.6.0.bb
b/meta/recipes-multimedia/libpng/libpng_1.6.0.bb
deleted file mode 100644
index 951e34a..000
--- a/meta/recipes-multimedia/libpng/libpng_1.6.0.bb
+++ /dev/null
@@ -1,20 +0,0 @@
-SUMMARY = PNG Library
-DESCRIPTION = PNG Library
-HOMEPAGE = http://www.libpng.org/;
-SECTION = libs
-LICENSE = Libpng
-LIC_FILES_CHKSUM = file://LICENSE;md5=03b8ec701cb796c0ec84af22f884edef \
-
file://png.h;beginline=207;endline=321;md5=e829cebefd08488ba5142ea5faea6821
-DEPENDS = zlib
-PR = r0
-LIBV = 16
-
-SRC_URI =
${SOURCEFORGE_MIRROR}/project/libpng/libpng${LIBV}/${PV}/libpng-${PV}.tar.xz \
-
-
-SRC_URI[md5sum] = 3ee623b9a4d33bda7310a5124080b14d
-SRC_URI[sha256sum] =
5e13c31321083b03956b5ff298bacffab7a7ad35c34c122acef314593944b97b
-
-inherit autotools binconfig pkgconfig
-
-BBCLASSEXTEND = native nativesdk
diff --git a/meta/recipes-multimedia/libpng/libpng_1.6.1.bb
b/meta/recipes-multimedia/libpng/libpng_1.6.1.bb
new file mode 100644
index 000..a05e380
--- /dev/null
+++ b/meta/recipes-multimedia/libpng/libpng_1.6.1.bb
@@ -0,0 +1,24 @@
+SUMMARY = PNG Library
+DESCRIPTION = PNG Library
+HOMEPAGE = http://www.libpng.org/;
+SECTION = libs
+LICENSE = Libpng
+LIC_FILES_CHKSUM = file://LICENSE;md5=8273188b2e21c831f5a09fd9285db62f \
+
file://png.h;beginline=207;endline=321;md5=de107fb61766e9d826943f3b6a354fc9 \
+
+DEPENDS = zlib
+PR = r0
+LIBV = 16
+
+SRC_URI =
${SOURCEFORGE_MIRROR}/project/libpng/libpng${LIBV}/${PV}/libpng-${PV}.tar.xz \
+ file://0001-configure-lower-automake-requirement.patch \
+
+
+SRC_URI[md5sum] = 93fc0b0841ce2db0e6756673e22dafc3
+SRC_URI[sha256sum] =
5ef57f8b9ef591c8504e2a8f78d31779f0c8f2b34b34d01d533360d2483c8946
+
+inherit autotools binconfig pkgconfig
+
+EXTRA_OECONF_append_arm = ${@bb.utils.contains(TUNE_FEATURES, neon,
--enable-arm-neon=on, --enable-arm-neon=off, d)}
+
+BBCLASSEXTEND = native nativesdk
--
1.7.9.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] package_rpm.bbclass: fix /etc/rpm/platform generation
On Thu, 2013-04-18 at 12:32 -0500, Mark Hatle wrote:
On 4/18/13 11:59 AM, Richard Purdie wrote:
On Thu, 2013-04-18 at 10:10 -0500, Mark Hatle wrote:
On 4/18/13 9:46 AM, Mark Hatle wrote:
On 4/18/13 9:27 AM, Bogdan Marinescu wrote:
For some platforms (for example emenlow) the RPM installer prefers
an invalid package architecture (for example i586 over core2) because
/etc/rpm/platform is not properly generated (for example, i586 is
listed before core2 in /etc/rpm/platform).
[YOCTO #3864]
Signed-off-by: Bogdan Marinescu bogdan.a.marine...@intel.com
---
meta/classes/package_rpm.bbclass |1 -
1 file changed, 1 deletion(-)
diff --git a/meta/classes/package_rpm.bbclass
b/meta/classes/package_rpm.bbclass
index 3a29976..1bee4b1 100644
--- a/meta/classes/package_rpm.bbclass
+++ b/meta/classes/package_rpm.bbclass
@@ -276,7 +276,6 @@ package_install_internal_rpm () {
# Setup base system configuration
echo Note: configuring RPM platform settings
mkdir -p ${target_rootfs}/etc/rpm/
-echo $INSTALL_PLATFORM_RPM
${target_rootfs}/etc/rpm/platform
I think this is wrong. The /etc/rpm/platform file's first line is
supposed to
be the equivalent of: [uname -m]-vendor-os. While uname -m doesn't
match our
tune namings, the concept is the same. The first line simply defines the
tune
of the platform, subsequent lines define alternative names that will run
on this
system.
The INSTALL_PLATFORM_RPM value should be the expected value for the
platform as
a whole, as it's the default tune value. (Default tune value is expected
to be
the most accurate value.
Looking at the defect:
i586-poky-linux
emenlow-.*-linux
core2-.*-linux
i686-.*-linux
i586-.*-linux
i486-.*-linux
i386-.*-linux
x86-.*-linux
noarch-.*-linux.*
any-.*-linux.*
all-.*-linux.*
The default tune value for that machine was set to i586 by something.
INSTALL_PLATFORM_RPM=$(echo ${TARGET_ARCH} | tr -
_)${TARGET_VENDOR}-${TARGET_OS}
${TARGET_ARCH} is similar to the output of uname -m. The error is that
this
particular BSP should have returned 'core2' as the TARGET_ARCH from what
I can tell.
Default for TARGET_ARCH is: TARGET_ARCH = ${TUNE_ARCH}
So the TUNE_ARCH is being set to i586. So the end result is.. Is
'TUNE_ARCH'
set to i586 appropriate? It probably is, because the majority of the
system
seems to have a limited set of expected values for TARGET_ARCH.
So, perhaps the right fix is instead of using 'TARGET_ARCH' in
INSTALL_PLATFORM_RPM, 'TUNE_PKGARCH_${DEFAULTTUNE}' may be more
appropriate.
I'd suggest trying that. (But the first line is the system architecture,
following lines are alternative packages that are considered compatible.)
Forgot one thing. The first line must be fully expanded. Subsequent
lines are
regex matched by the system.
We have a problem here since the machine specific packages are meant to
be preferred over the tune specific ones by definition of the way OE
has long since worked, the structure of the PACKAGE_ARCHS variable and
so on.
As I understand it, this will not happen with this file setup in this
way.
Ordering is defined by the lines -after- the first one.. the first line is
defined as the system arch.
The function rpmPlaform(...) in lib/rpmrc.c controls the loading of this data.
The first time through is reads the first line and sets:
_platform_cpu
_platform_vendor
_platform_os
_platform_gnu
The _platform items are used by the _host_* requivalent macros.. this
defines
the core system items.
Subsequent lines are then loaded and added to the regex for 'supported'
platforms/package archs. (The 'arch' field in a package is useless.. it's
just
a key but doesn't really mean anything in RPM 5. It's the 'platform' field
embedded into the package that is actually used for compatibility.)
The machine ordering SHOULD come from the 'platformScore' function (also in
lib/rpmrc.c). That only uses the regex to figure out the proper 'score' for
a
component. (roughly matches the line number in the file)
That being said, this stuff doesn't actually affect smart -directly-, it only
affects it indirectly. When a package is selected by smart (which has it's
own
ordering tools) it verified compatibility using these components.
For image generate, the package order is defined by us adding the places to
look
one at a time. The only place I've seen a similar problem is when someone
moves
all of the packages into a single directory and says 'here ya go'. I don't
know
how smart selects which packages to favor in that case. If someone could
point
that out, it may turn out it's a bug in smart -- or a problem we need to fix
in
another way.
There is a python function 'archScore'. What this does is take the
Re: [OE-core] postinst does not finish
On 04/19/2013 02:38 PM, Koen Kooi wrote: Op 19 apr. 2013, om 13:23 heeft Laurentiu Palcu laurentiu.pa...@intel.com het volgende geschreven: On 04/19/2013 12:13 PM, Koen Kooi wrote: Op 19 apr. 2013, om 10:52 heeft Burton, Ross ross.bur...@intel.com het volgende geschreven: On 19 April 2013 09:38, Burton, Ross ross.bur...@intel.com wrote: On 18 April 2013 19:45, Koen Kooi k...@dominion.thruhere.net wrote: [koen@rrMBP 1.0-r0]$ grep configuration required on target temp/log.do_rootfs gdk-pixbuf-loader-png.postinst returned 1, marking as unpacked only, configuration required on target. .. This is usual for postinsts that are intercepted and handled in a single go - scroll further down the log and you should see the package manager running the intercept scripts (i.e. fontcaches once, gconftool once). I expect you'll see there that the gconftool intercept is breaking for some reason. Actually gconf isn't using triggers but it should happen on the host. I wonder if we're hitting a problem where the postinsts are doing some actions on the host and then triggers are erroring out and it's all falling back to the target. Can you share the complete rootfs log for this gnome image? Here's the complete log: http://dominion.thruhere.net/koen/angstrom/beaglebone/log.do_rootfs Do you think you can post the rootfs/var/lib/opkg/status file? This would show us exactly what packages were postponed for first boot. This is the build that finished just before Ross sent the gconf patch: http://dominion.thruhere.net/koen/angstrom/beaglebone/Angstrom-systemd-GNOME-image-eglibc-ipk-v2013.06-beaglebone.rootfs.tar.xz (75MiB) I haven't booted that yet, I'll do that when I get back from lunch. From what you sent, I see the following packages postponed: udev-hwdb, gnome-panel and gdm. We know about udev-hwdb... However, gnome-panel and gdm are postponing the postinstalls for first boot explicitly: if [ x$D != x ]; then exit1 fi This explains, at least, why you still see postinstalls running at first boot. Running the postinstalls at first boot appear to hang because (and that's just a feeling) gtk-icon-cache is run twice on target... which is time consuming. Thanks, Laurentiu regards, Koen Thanks, Laurentiu Todays build is still building :( ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] postinst does not finish
Op 19 apr. 2013, om 14:26 heeft Laurentiu Palcu laurentiu.pa...@intel.com het volgende geschreven: On 04/19/2013 02:38 PM, Koen Kooi wrote: Op 19 apr. 2013, om 13:23 heeft Laurentiu Palcu laurentiu.pa...@intel.com het volgende geschreven: On 04/19/2013 12:13 PM, Koen Kooi wrote: Op 19 apr. 2013, om 10:52 heeft Burton, Ross ross.bur...@intel.com het volgende geschreven: On 19 April 2013 09:38, Burton, Ross ross.bur...@intel.com wrote: On 18 April 2013 19:45, Koen Kooi k...@dominion.thruhere.net wrote: [koen@rrMBP 1.0-r0]$ grep configuration required on target temp/log.do_rootfs gdk-pixbuf-loader-png.postinst returned 1, marking as unpacked only, configuration required on target. .. This is usual for postinsts that are intercepted and handled in a single go - scroll further down the log and you should see the package manager running the intercept scripts (i.e. fontcaches once, gconftool once). I expect you'll see there that the gconftool intercept is breaking for some reason. Actually gconf isn't using triggers but it should happen on the host. I wonder if we're hitting a problem where the postinsts are doing some actions on the host and then triggers are erroring out and it's all falling back to the target. Can you share the complete rootfs log for this gnome image? Here's the complete log: http://dominion.thruhere.net/koen/angstrom/beaglebone/log.do_rootfs Do you think you can post the rootfs/var/lib/opkg/status file? This would show us exactly what packages were postponed for first boot. This is the build that finished just before Ross sent the gconf patch: http://dominion.thruhere.net/koen/angstrom/beaglebone/Angstrom-systemd-GNOME-image-eglibc-ipk-v2013.06-beaglebone.rootfs.tar.xz (75MiB) I haven't booted that yet, I'll do that when I get back from lunch. From what you sent, I see the following packages postponed: udev-hwdb, gnome-panel and gdm. We know about udev-hwdb... However, gnome-panel and gdm are postponing the postinstalls for first boot explicitly: if [ x$D != x ]; then exit1 fi This explains, at least, why you still see postinstalls running at first boot. Running the postinstalls at first boot appear to hang because (and that's just a feeling) gtk-icon-cache is run twice on target... which is time consuming. I know it's time consuming, but it finished on 60-90 minutes with 1.3, I left it overnight and it still hadn't finished. I have the LEDS configured to short mmc0 and cpu0 activity and there' s no IO, only cpu from time to time. I don't think it takes more than 14 hours to run those postinsts. regards, Koen ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gdk-pixbuf: Fix libpng determinism issues
On Mon, 2013-04-15 at 08:59 -0400, Colin Walters wrote: On Mon, 2013-04-15 at 13:22 +0100, Richard Purdie wrote: On Mon, 2013-04-15 at 08:12 -0400, Colin Walters wrote: On Mon, 2013-04-15 at 12:31 +0100, Richard Purdie wrote: It will make our builds work again for now until the next time someone upgrades libpng and and then it will potentially silently start using an old version in some builds :(. So something like the attached on top of the previous patch? If this looks good I'll push both to master. Looks good to me, thanks! Both pushed to git, thanks. Much appreciated! nag If OE was building from git as it should, your original patch could have been a ready-to-upstream git format-patch style instead of the default Upstream-Status: inappropriate non-git patches =/ /nag Noted, although I doubt we'll be using git SRC_URIs for everything any time soon for a variety of reasons. I would love to see the option of building most things from bleeding source but that would require a lot of work which we don't have the bandwidth for. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] postinst does not finish
On 19 April 2013 13:49, Koen Kooi k...@dominion.thruhere.net wrote: Running the postinstalls at first boot appear to hang because (and that's just a feeling) gtk-icon-cache is run twice on target... which is time consuming. I know it's time consuming, but it finished on 60-90 minutes with 1.3, I left it overnight and it still hadn't finished. I have the LEDS configured to short mmc0 and cpu0 activity and there' s no IO, only cpu from time to time. I don't think it takes more than 14 hours to run those postinsts. How about hacking the postinsts to use sh -x, so you can see what it's executing? Ross ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] connman-gnome: Replace broken png files
connman-signal-*.png files were corrupted and this caused
warnings when starting connman-applet.
The patch overwrites the upstream png files.
[YOCTO #4060]
Signed-off-by: Emilia Ciobanu emilia.maria.silvia.ciob...@intel.com
---
.../connman-gnome/images/connman-signal-01.png | Bin 0 - 490 bytes
.../connman-gnome/images/connman-signal-02.png | Bin 0 - 496 bytes
.../connman-gnome/images/connman-signal-03.png | Bin 0 - 492 bytes
.../connman-gnome/images/connman-signal-04.png | Bin 0 - 470 bytes
.../connman-gnome/images/connman-signal-05.png | Bin 0 - 419 bytes
.../connman/connman-gnome_0.7.bb |8 +++-
6 files changed, 7 insertions(+), 1 deletion(-)
create mode 100644
meta/recipes-connectivity/connman/connman-gnome/images/connman-signal-01.png
create mode 100644
meta/recipes-connectivity/connman/connman-gnome/images/connman-signal-02.png
create mode 100644
meta/recipes-connectivity/connman/connman-gnome/images/connman-signal-03.png
create mode 100644
meta/recipes-connectivity/connman/connman-gnome/images/connman-signal-04.png
create mode 100644
meta/recipes-connectivity/connman/connman-gnome/images/connman-signal-05.png
diff --git
a/meta/recipes-connectivity/connman/connman-gnome/images/connman-signal-01.png
b/meta/recipes-connectivity/connman/connman-gnome/images/connman-signal-01.png
new file mode 100644
index
..33247c1e2db4304e48ea0a6145be4de6e420882b
GIT binary patch
literal 490
zcmVG0TupP)h;3K|Lk000e1NJLTq000M000U1^@s6#I$TX6VoOIv0RI60
z0RN!9r;`8x010qNS#tmY3ljhU3ljkVnw%H_000McNliru)Cvt2G}Dr@$)y03CEi
zSad^gZEa4bO1wgWnpwWFU8GbZ8({Xk{QrNlj4iWF9@00B-(L_t(I%k5O5PD4Qu
zoZXqdq)#-6CMbeI5`w`$RU9NZfX`@|AHhTL4hLyM{3F^@J9~;@3_|%O7kEX*6rQx
z?C#9o0{`~gWBGlGk)D-s8f2SC_Q`Xv}bSev!|611l1?clPGbd$hg_;6(~J383i(
zjJw;L+TNu(J~@RV;BK%PxmE@a1vWOfGK`c!=gLfw;loMBP=37cfeMx`0?SshBYua
z4i1k%CQyPkZ=8}X$193Q38T?^L4}|~EQR3oS?%V4r)|smfdY{N*0hNNEGi`9dmK+D
zPiqF$4GiP){A2gNGKDPz@k8RG`0j-N*E4@g)gLt{QDUKrA!4S7zxKxV4q2^p^s
zl(k(AZMpSch6#eDc+!}fZ}1K=-j)yKaK9+n~G{M==dq6ZV*}K?Qs6t+AOD{GaUT
g(S7{`tN4%X6`T(*H@KiqKz%07*qoM6N$g7W0Y-2eap
literal 0
HcmV?d1
diff --git
a/meta/recipes-connectivity/connman/connman-gnome/images/connman-signal-02.png
b/meta/recipes-connectivity/connman/connman-gnome/images/connman-signal-02.png
new file mode 100644
index
..a94fb952ff6cbea25b06c261267fe9a82d77f981
GIT binary patch
literal 496
zcmVM0T2F(P)h;3K|Lk000e1NJLTq000M000U1^@s6#I$TX6VoOIv0RI60
z0RN!9r;`8x010qNS#tmY3ljhU3ljkVnw%H_000McNliru)Cvt2G$Z^+X`%oC03CEi
zSad^gZEa4bO1wgWnpwWFU8GbZ8({Xk{QrNlj4iWF9@00C4L_t(I%k5M#N(4a=
ztnRL!*xlOOfD2LG2a`n287mV(1GD{eYn$7H(q=E52H03YB)SEHT9cOP(@0L|e
z?5tEYpScd2l$WQ4(VAxn#ijflYN;ot{(zAciA;4q)}2BrtBtgg4ud$hg=;E{Bw
z8GzIa7+06)m3yUy|V|pLscLXc6A1JI+m7)8HNlnwa!wsTXzTfS?2CARX{p2zP-7w
zAPEA+#^x5x0*r*DcTLS|jXRoWBnE@ULJER~S#~8C%tO{kLs554|I5NNUAS#Si#WD
z=hOK3;%VVygK)GvyrVt1Imj^UaenNHT{MccX^_hzRa^`^^avlK=`%%HOv#~2aE
zpB5k+(Uj1Olox7^-SE^Go1yOc=kuG-o$BUdz%~WS=9Aj(hY*@YW+(~TlyQ@9
mrlK(Q)1fpIa_UKZ-X`7C)%O7ejFXMNUMnLSTZlN5kg;
literal 0
HcmV?d1
diff --git
a/meta/recipes-connectivity/connman/connman-gnome/images/connman-signal-03.png
b/meta/recipes-connectivity/connman/connman-gnome/images/connman-signal-03.png
new file mode 100644
index
..b5eb405a9009722025c1e93e233f8dec676ff9fd
GIT binary patch
literal 492
zcmVI0Tcd-P)h;3K|Lk000e1NJLTq000M000U1^@s6#I$TX6VoOIv0RI60
z0RN!9r;`8x010qNS#tmY3ljhU3ljkVnw%H_000McNliru)Cvt2GzlmCpmYEL03CEi
zSad^gZEa4bO1wgWnpwWFU8GbZ8({Xk{QrNlj4iWF9@00B@*L_t(I%k5MPQySD
zee+Ar1rSY2glOn}4TK_5AWBYG8dpkLZXPsDL|nv~Yl2Byo0@g7~v`APEN1FxBkX
z^YrGu*#-XNw}U$NPaEf~z|^kHZf~wL0uYICad}nNI|HlraCmgmu6G#y7{HsVfkgns
zPQaMl-(|G2=Jf0wY6fNkHSF3M*wnCp@W+Bdk~hLrD%_C2Gy#~%plAF?Z|jEo@GTo
z9P}a5gQ$YyhoNh#@{gS@#VE9g+gm)sVP{v0JwWT8x}jeOacW2B|R=vF$V-jc0qS
z8-(GY|Ktf%e-o60IMj38IiV-;$iw+=FtOUm{$xA*!Vmq6!iLZ({83@UW=P0a)gX
z+T%h{mV_ZQmu7wn96Tb_Mt66F`8@fDHN9!Vyjf#+Pk;j=@;n7r5!4CFnsuWuwxYcq
iX{`I6{lHWFNAV8gNn5(2{=AIMNUMnLSTYw4$qnZ
literal 0
HcmV?d1
diff --git
a/meta/recipes-connectivity/connman/connman-gnome/images/connman-signal-04.png
b/meta/recipes-connectivity/connman/connman-gnome/images/connman-signal-04.png
new file mode 100644
index
..be54419fa74db126c4039c27566584e5b4d5c26e
GIT binary patch
literal 470
zcmeAS@N?(olHy`uVBq!ia0vp^Vj#@H1|*Mc$*~4fY)RhkE)4%caKYZ?lYt_f1s;*b
z3=G`DAk4@xYmNj^kiEpy*OmPW7q6HxgJ5ExI8aEo#5JPCIX^cyHLrxhxhOTUBsE2$
zJhLQ2AtWPJ!QIn0;C+f}9siTm8Xkih{fr*A%=cO3PA}-wOZSp)I*;d%FUQtb0
zIQ5%BRp@RlGY4yc;z8zjvIU-RVx@$R^98-rQ;=GAei=}va*~9^80yKi15=UuhJ
zxz_HT`?Po%Oxd1`PrvsCFymVg`K7JI{%EnA_rz~vYUTpe~ra^`6Mv??r~~rF@I
zYSPyo!|vGcbz!n*7Ji?5bU`UYfNxW;sm7wZq65+p-tG{XTEcXgfbVRKgQL!Ua
zgVJAe2adkV5fOCV^M{AfB5UO7q9akDl)7WV7+4gQC_Lx3)M7IM`g+Igpsukd3s
z35k{6!;~m38qIx}M=DrHX+pqpD~5e5C)d7z{e(yG;ENNioQpUjUoU*6*pqZ4*hC
Re: [OE-core] postinst does not finish
Op 19 apr. 2013, om 15:03 heeft Burton, Ross ross.bur...@intel.com het volgende geschreven: On 19 April 2013 13:49, Koen Kooi k...@dominion.thruhere.net wrote: Running the postinstalls at first boot appear to hang because (and that's just a feeling) gtk-icon-cache is run twice on target... which is time consuming. I know it's time consuming, but it finished on 60-90 minutes with 1.3, I left it overnight and it still hadn't finished. I have the LEDS configured to short mmc0 and cpu0 activity and there' s no IO, only cpu from time to time. I don't think it takes more than 14 hours to run those postinsts. How about hacking the postinsts to use sh -x, so you can see what it's executing? Going to do that in a minute. Todays build just finished (*$(@*$(@ webkit-gtk build times) and I added timeoutsec=600 to the .service file: root@beaglebone:~# systemctl status run-postinsts -a run-postinsts.service - Run pending postinsts Loaded: loaded (/lib/systemd/system/run-postinsts.service; disabled) Active: failed (Result: timeout) since Sat 2000-01-01 18:30:33 UTC; 13 years 3 months ago Main PID: 122 CGroup: name=systemd:/system/run-postinsts.service Jan 01 18:20:33 beaglebone S98run-postinsts[122]: adduser: group gdm does not exist Jan 01 18:20:33 beaglebone S98run-postinsts[122]: chown: unknown user/group gdm:gdm Jan 01 18:30:33 beaglebone systemd[1]: run-postinsts.service operation timed out. Terminating. Jan 01 18:30:33 beaglebone systemd[1]: Failed to start Run pending postinsts. Jan 01 18:30:33 beaglebone systemd[1]: MESSAGE=Unit run-postinsts.service entered failed state. root@beaglebone:~# So it seems to just hang. Will report about the set -x thing shortly. regards, Koen ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] postinst does not finish
Op 19 apr. 2013, om 15:13 heeft Koen Kooi k...@dominion.thruhere.net het volgende geschreven: Op 19 apr. 2013, om 15:03 heeft Burton, Ross ross.bur...@intel.com het volgende geschreven: On 19 April 2013 13:49, Koen Kooi k...@dominion.thruhere.net wrote: Running the postinstalls at first boot appear to hang because (and that's just a feeling) gtk-icon-cache is run twice on target... which is time consuming. I know it's time consuming, but it finished on 60-90 minutes with 1.3, I left it overnight and it still hadn't finished. I have the LEDS configured to short mmc0 and cpu0 activity and there' s no IO, only cpu from time to time. I don't think it takes more than 14 hours to run those postinsts. How about hacking the postinsts to use sh -x, so you can see what it's executing? Going to do that in a minute. Todays build just finished (*$(@*$(@ webkit-gtk build times) and I added timeoutsec=600 to the .service file: root@beaglebone:~# systemctl status run-postinsts -a run-postinsts.service - Run pending postinsts Loaded: loaded (/lib/systemd/system/run-postinsts.service; disabled) Active: failed (Result: timeout) since Sat 2000-01-01 18:30:33 UTC; 13 years 3 months ago Main PID: 122 CGroup: name=systemd:/system/run-postinsts.service Jan 01 18:20:33 beaglebone S98run-postinsts[122]: adduser: group gdm does not exist Jan 01 18:20:33 beaglebone S98run-postinsts[122]: chown: unknown user/group gdm:gdm Jan 01 18:30:33 beaglebone systemd[1]: run-postinsts.service operation timed out. Terminating. Jan 01 18:30:33 beaglebone systemd[1]: Failed to start Run pending postinsts. Jan 01 18:30:33 beaglebone systemd[1]: MESSAGE=Unit run-postinsts.service entered failed state. root@beaglebone:~# So it seems to just hang. Will report about the set -x thing shortly. And here it is: Change postinst.service to Type=simple root@beaglebone:~# journalctl -a -f -b -n500 -u run-postinsts -- Logs begin at Sat 2000-01-01 18:47:13 UTC. -- Jan 01 18:47:21 beaglebone S98run-postinsts[125]: ++ '[' x '!=' x ']' Jan 01 18:47:21 beaglebone S98run-postinsts[125]: ++ grep '^gdm:' /etc/group Jan 01 18:47:21 beaglebone S98run-postinsts[125]: ++ addgroup gdm Jan 01 18:47:21 beaglebone S98run-postinsts[125]: ++ grep '^gdm:' /etc/passwd Jan 01 18:47:21 beaglebone S98run-postinsts[125]: ++ adduser --disabled-password --system --home /var/lib/gdm gdm --ingroup gdm -g gdm Jan 01 18:47:21 beaglebone S98run-postinsts[125]: adduser: /var/lib/gdm: File exists Jan 01 18:47:21 beaglebone S98run-postinsts[125]: ++ '[' -d /var/lib/gdm ']' Jan 01 18:47:21 beaglebone S98run-postinsts[125]: ++ chown -R gdm:gdm /var/lib/gdm Jan 01 18:47:21 beaglebone S98run-postinsts[125]: chown: unknown user/group gdm:gdm Jan 01 18:47:21 beaglebone S98run-postinsts[125]: ++ chmod 0750 /var/lib/gdm Jan 01 18:47:21 beaglebone S98run-postinsts[125]: ++ mkdir -p /etc/X11/ Jan 01 18:47:21 beaglebone S98run-postinsts[125]: ++ echo /usr/bin/gdm Jan 01 18:47:21 beaglebone S98run-postinsts[125]: ++ OPTS= Jan 01 18:47:21 beaglebone S98run-postinsts[125]: ++ '[' -n '' ']' Jan 01 18:47:21 beaglebone S98run-postinsts[125]: ++ type systemctl Jan 01 18:47:21 beaglebone S98run-postinsts[125]: ++ systemctl enable gdm.service Jan 01 18:47:21 beaglebone S98run-postinsts[125]: ++ '[' -z '' -a enable = enable ']' Jan 01 18:47:21 beaglebone S98run-postinsts[125]: ++ systemctl restart gdm.service Jan 01 18:47:21 beaglebone S98run-postinsts[125]: ++ test x '!=' x Jan 01 18:47:21 beaglebone S98run-postinsts[125]: ++ OPT=-s Jan 01 18:47:21 beaglebone S98run-postinsts[125]: ++ type update-rc.d Jan 01 18:47:21 beaglebone S98run-postinsts[125]: ++ update-rc.d -s gdm start 99 5 2 . stop 20 0 1 6 . Jan 01 18:47:21 beaglebone S98run-postinsts[125]: Adding system startup for /etc/init.d/gdm. Jan 01 18:47:22 beaglebone S98run-postinsts[125]: ++ '[' x '!=' x ']' Jan 01 18:47:22 beaglebone S98run-postinsts[125]: ++ GDK_PIXBUF_MODULEDIR=/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders Jan 01 18:47:22 beaglebone S98run-postinsts[125]: ++ gdk-pixbuf-query-loaders --update-cache Jan 01 18:47:22 beaglebone S98run-postinsts[125]: ++ for icondir in '/usr/share/icons/*' Jan 01 18:47:22 beaglebone S98run-postinsts[125]: ++ '[' -d /usr/share/icons/Crux ']' Jan 01 18:47:22 beaglebone S98run-postinsts[125]: ++ gtk-update-icon-cache -fqt /usr/share/icons/Crux Jan 01 18:47:22 beaglebone S98run-postinsts[125]: ++ for icondir in '/usr/share/icons/*' Jan 01 18:47:22 beaglebone S98run-postinsts[125]: ++ '[' -d /usr/share/icons/HighContrast ']' Jan 01 18:47:22 beaglebone S98run-postinsts[125]: ++ gtk-update-icon-cache -fqt /usr/share/icons/HighContrast Jan 01 18:47:22 beaglebone S98run-postinsts[125]: ++ for icondir in '/usr/share/icons/*' Jan 01 18:47:22 beaglebone S98run-postinsts[125]: ++ '[' -d /usr/share/icons/HighContrast-SVG ']' Jan 01 18:47:22 beaglebone S98run-postinsts[125]: ++ gtk-update-icon-cache -fqt /usr/share/icons/HighContrast-SVG
Re: [OE-core] [PATCH] gdk-pixbuf: Fix libpng determinism issues
Op 19 apr. 2013, om 14:59 heeft Richard Purdie richard.pur...@linuxfoundation.org het volgende geschreven: On Mon, 2013-04-15 at 08:59 -0400, Colin Walters wrote: On Mon, 2013-04-15 at 13:22 +0100, Richard Purdie wrote: On Mon, 2013-04-15 at 08:12 -0400, Colin Walters wrote: On Mon, 2013-04-15 at 12:31 +0100, Richard Purdie wrote: It will make our builds work again for now until the next time someone upgrades libpng and and then it will potentially silently start using an old version in some builds :(. So something like the attached on top of the previous patch? If this looks good I'll push both to master. Looks good to me, thanks! Both pushed to git, thanks. Much appreciated! nag If OE was building from git as it should, your original patch could have been a ready-to-upstream git format-patch style instead of the default Upstream-Status: inappropriate non-git patches =/ /nag Noted, although I doubt we'll be using git SRC_URIs for everything any time soon for a variety of reasons. I would love to see the option of building most things from bleeding source but that would require a lot of work which we don't have the bandwidth for. And would introduce some dependency hell (gtk-doc-native needed for every little gnome thing *and* udev) but more importantly it will expose us to that stupid, stupid, stupid practice of using git submodules to drag in autoconf stuff. Gstreamer is the worst offender, but there are a lot of others. I try to have recipe build from a git tag instead of a tarball whenever possible, but it hurts a lot if it's one of that gtk-doc users, you can't disable that completely. regards, Koen ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] postinst does not finish
Op 19 apr. 2013, om 15:37 heeft Koen Kooi k...@dominion.thruhere.net het volgende geschreven: Op 19 apr. 2013, om 15:13 heeft Koen Kooi k...@dominion.thruhere.net het volgende geschreven: Op 19 apr. 2013, om 15:03 heeft Burton, Ross ross.bur...@intel.com het volgende geschreven: On 19 April 2013 13:49, Koen Kooi k...@dominion.thruhere.net wrote: Running the postinstalls at first boot appear to hang because (and that's just a feeling) gtk-icon-cache is run twice on target... which is time consuming. I know it's time consuming, but it finished on 60-90 minutes with 1.3, I left it overnight and it still hadn't finished. I have the LEDS configured to short mmc0 and cpu0 activity and there' s no IO, only cpu from time to time. I don't think it takes more than 14 hours to run those postinsts. How about hacking the postinsts to use sh -x, so you can see what it's executing? Going to do that in a minute. Todays build just finished (*$(@*$(@ webkit-gtk build times) and I added timeoutsec=600 to the .service file: root@beaglebone:~# systemctl status run-postinsts -a run-postinsts.service - Run pending postinsts Loaded: loaded (/lib/systemd/system/run-postinsts.service; disabled) Active: failed (Result: timeout) since Sat 2000-01-01 18:30:33 UTC; 13 years 3 months ago Main PID: 122 CGroup: name=systemd:/system/run-postinsts.service Jan 01 18:20:33 beaglebone S98run-postinsts[122]: adduser: group gdm does not exist Jan 01 18:20:33 beaglebone S98run-postinsts[122]: chown: unknown user/group gdm:gdm Jan 01 18:30:33 beaglebone systemd[1]: run-postinsts.service operation timed out. Terminating. Jan 01 18:30:33 beaglebone systemd[1]: Failed to start Run pending postinsts. Jan 01 18:30:33 beaglebone systemd[1]: MESSAGE=Unit run-postinsts.service entered failed state. root@beaglebone:~# So it seems to just hang. Will report about the set -x thing shortly. And here it is: Change postinst.service to Type=simple root@beaglebone:~# journalctl -a -f -b -n500 -u run-postinsts -- Logs begin at Sat 2000-01-01 18:47:13 UTC. -- Jan 01 18:47:21 beaglebone S98run-postinsts[125]: ++ '[' x '!=' x ']' Jan 01 18:47:21 beaglebone S98run-postinsts[125]: ++ grep '^gdm:' /etc/group Jan 01 18:47:21 beaglebone S98run-postinsts[125]: ++ addgroup gdm Jan 01 18:47:21 beaglebone S98run-postinsts[125]: ++ grep '^gdm:' /etc/passwd Jan 01 18:47:21 beaglebone S98run-postinsts[125]: ++ adduser --disabled-password --system --home /var/lib/gdm gdm --ingroup gdm -g gdm Jan 01 18:47:21 beaglebone S98run-postinsts[125]: adduser: /var/lib/gdm: File exists Jan 01 18:47:21 beaglebone S98run-postinsts[125]: ++ '[' -d /var/lib/gdm ']' Jan 01 18:47:21 beaglebone S98run-postinsts[125]: ++ chown -R gdm:gdm /var/lib/gdm Jan 01 18:47:21 beaglebone S98run-postinsts[125]: chown: unknown user/group gdm:gdm Jan 01 18:47:21 beaglebone S98run-postinsts[125]: ++ chmod 0750 /var/lib/gdm Jan 01 18:47:21 beaglebone S98run-postinsts[125]: ++ mkdir -p /etc/X11/ Jan 01 18:47:21 beaglebone S98run-postinsts[125]: ++ echo /usr/bin/gdm Jan 01 18:47:21 beaglebone S98run-postinsts[125]: ++ OPTS= Jan 01 18:47:21 beaglebone S98run-postinsts[125]: ++ '[' -n '' ']' Jan 01 18:47:21 beaglebone S98run-postinsts[125]: ++ type systemctl Jan 01 18:47:21 beaglebone S98run-postinsts[125]: ++ systemctl enable gdm.service Jan 01 18:47:21 beaglebone S98run-postinsts[125]: ++ '[' -z '' -a enable = enable ']' Jan 01 18:47:21 beaglebone S98run-postinsts[125]: ++ systemctl restart gdm.service Jan 01 18:47:21 beaglebone S98run-postinsts[125]: ++ test x '!=' x Jan 01 18:47:21 beaglebone S98run-postinsts[125]: ++ OPT=-s Jan 01 18:47:21 beaglebone S98run-postinsts[125]: ++ type update-rc.d Jan 01 18:47:21 beaglebone S98run-postinsts[125]: ++ update-rc.d -s gdm start 99 5 2 . stop 20 0 1 6 . Jan 01 18:47:21 beaglebone S98run-postinsts[125]: Adding system startup for /etc/init.d/gdm. Jan 01 18:47:22 beaglebone S98run-postinsts[125]: ++ '[' x '!=' x ']' Jan 01 18:47:22 beaglebone S98run-postinsts[125]: ++ GDK_PIXBUF_MODULEDIR=/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders Jan 01 18:47:22 beaglebone S98run-postinsts[125]: ++ gdk-pixbuf-query-loaders --update-cache Jan 01 18:47:22 beaglebone S98run-postinsts[125]: ++ for icondir in '/usr/share/icons/*' Jan 01 18:47:22 beaglebone S98run-postinsts[125]: ++ '[' -d /usr/share/icons/Crux ']' Jan 01 18:47:22 beaglebone S98run-postinsts[125]: ++ gtk-update-icon-cache -fqt /usr/share/icons/Crux Jan 01 18:47:22 beaglebone S98run-postinsts[125]: ++ for icondir in '/usr/share/icons/*' Jan 01 18:47:22 beaglebone S98run-postinsts[125]: ++ '[' -d /usr/share/icons/HighContrast ']' Jan 01 18:47:22 beaglebone S98run-postinsts[125]: ++ gtk-update-icon-cache -fqt /usr/share/icons/HighContrast Jan 01 18:47:22 beaglebone S98run-postinsts[125]: ++ for icondir in '/usr/share/icons/*' Jan 01 18:47:22 beaglebone S98run-postinsts[125]: ++ '[' -d
Re: [OE-core] postinst does not finish
Op 19 apr. 2013, om 16:00 heeft Koen Kooi k...@dominion.thruhere.net het volgende geschreven: Op 19 apr. 2013, om 15:37 heeft Koen Kooi k...@dominion.thruhere.net het volgende geschreven: Op 19 apr. 2013, om 15:13 heeft Koen Kooi k...@dominion.thruhere.net het volgende geschreven: Op 19 apr. 2013, om 15:03 heeft Burton, Ross ross.bur...@intel.com het volgende geschreven: On 19 April 2013 13:49, Koen Kooi k...@dominion.thruhere.net wrote: Running the postinstalls at first boot appear to hang because (and that's just a feeling) gtk-icon-cache is run twice on target... which is time consuming. I know it's time consuming, but it finished on 60-90 minutes with 1.3, I left it overnight and it still hadn't finished. I have the LEDS configured to short mmc0 and cpu0 activity and there' s no IO, only cpu from time to time. I don't think it takes more than 14 hours to run those postinsts. How about hacking the postinsts to use sh -x, so you can see what it's executing? Going to do that in a minute. Todays build just finished (*$(@*$(@ webkit-gtk build times) and I added timeoutsec=600 to the .service file: root@beaglebone:~# systemctl status run-postinsts -a run-postinsts.service - Run pending postinsts Loaded: loaded (/lib/systemd/system/run-postinsts.service; disabled) Active: failed (Result: timeout) since Sat 2000-01-01 18:30:33 UTC; 13 years 3 months ago Main PID: 122 CGroup: name=systemd:/system/run-postinsts.service Jan 01 18:20:33 beaglebone S98run-postinsts[122]: adduser: group gdm does not exist Jan 01 18:20:33 beaglebone S98run-postinsts[122]: chown: unknown user/group gdm:gdm Jan 01 18:30:33 beaglebone systemd[1]: run-postinsts.service operation timed out. Terminating. Jan 01 18:30:33 beaglebone systemd[1]: Failed to start Run pending postinsts. Jan 01 18:30:33 beaglebone systemd[1]: MESSAGE=Unit run-postinsts.service entered failed state. root@beaglebone:~# So it seems to just hang. Will report about the set -x thing shortly. And here it is: Change postinst.service to Type=simple [ snip] root@beaglebone:~# ls /etc/rcS.d S03systemd-udevd root@beaglebone:~# So it completed this time. This is the 5th reboot already. I have no idea why it finished this time :( And it still doesn't work :( root@beaglebone:~# systemctl status gdm -a gdm.service - Gnome Display Manager Loaded: loaded (/lib/systemd/system/gdm.service; enabled) Active: active (running) since Sat 2000-01-01 19:22:11 UTC; 13 years 3 months ago Main PID: 147 (gdm-binary) CGroup: name=systemd:/system/gdm.service └─147 /usr/sbin/gdm-binary -nodaemon Apr 19 13:56:22 beaglebone gdm-simple-slave[326]: WARNING: Couldn't look up uid Apr 19 13:56:22 beaglebone gdm-simple-slave[337]: WARNING: User gdm doesn't exist Apr 19 13:56:22 beaglebone gdm-simple-slave[326]: WARNING: Unable to parse output: Apr 19 13:56:22 beaglebone gdm-simple-slave[326]: WARNING: Unable to parse D-Bus launch output Apr 19 13:56:22 beaglebone gdm-simple-slave[338]: WARNING: User gdm doesn't exist Apr 19 13:56:22 beaglebone gdm-simple-slave[326]: WARNING: Could not run helper: Failed to execute child process /usr/lib/gdm/ck-get-x11-display-device (No such file or directory) Apr 19 13:56:22 beaglebone gdm[147]: gdm-binary[147]: WARNING: GdmDisplay: display lasted 1.401004 seconds Apr 19 13:56:22 beaglebone gdm-binary[147]: WARNING: GdmDisplay: display lasted 1.401004 seconds Apr 19 13:56:22 beaglebone gdm-binary[147]: WARNING: GdmLocalDisplayFactory: maximum number of X display failures reached: check X server log for errors Apr 19 13:56:22 beaglebone gdm[147]: gdm-binary[147]: WARNING: GdmLocalDisplayFactory: maximum number of X display failures reached: check X server log for errors Hmm, let's rerun gdm.postinst: root@beaglebone:~# sh /var/lib/opkg/info/gdm.postinst + '[' x '!=' x ']' + grep '^gdm:' /etc/group + grep '^gdm:' /etc/passwd + adduser --disabled-password --system --home /var/lib/gdm gdm --ingroup gdm -g gdm adduser: /var/lib/gdm: File exists + '[' -d /var/lib/gdm ']' + chown -R gdm:gdm /var/lib/gdm + chmod 0750 /var/lib/gdm + mkdir -p /etc/X11/ + echo /usr/bin/gdm + OPTS= + '[' -n '' ']' + type systemctl + systemctl enable gdm.service + '[' -z '' -a enable = enable ']' + systemctl restart gdm.service + test x '!=' x + OPT=-s + type update-rc.d + update-rc.d -s gdm start 99 5 2 . stop 20 0 1 6 . System startup links for /etc/init.d/gdm already exist. + '[' x '!=' x ']' + GDK_PIXBUF_MODULEDIR=/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders + gdk-pixbuf-query-loaders --update-cache [ 102.324520] tilcdc 4830e000.fb: timeout waiting for framedone + for icondir in '/usr/share/icons/*' + '[' -d /usr/share/icons/Crux ']' + gtk-update-icon-cache -fqt /usr/share/icons/Crux + for icondir in '/usr/share/icons/*' + '[' -d /usr/share/icons/HighContrast ']' + gtk-update-icon-cache -fqt
Re: [OE-core] [PATCH] libpng: Upgrade to 1.6.1
On 04/19/2013 05:07 AM, Emilia Ciobanu wrote:
Signed-off-by: Emilia Ciobanu emilia.maria.silvia.ciob...@intel.com
This update has already been offered up by Koen, I will be taking his
version once we clear 1.4 from the table.
Very soon now.
Sau!
---
...0001-configure-lower-automake-requirement.patch | 29
meta/recipes-multimedia/libpng/libpng_1.6.0.bb | 20 --
meta/recipes-multimedia/libpng/libpng_1.6.1.bb | 24
3 files changed, 53 insertions(+), 20 deletions(-)
create mode 100644
meta/recipes-multimedia/libpng/libpng/0001-configure-lower-automake-requirement.patch
delete mode 100644 meta/recipes-multimedia/libpng/libpng_1.6.0.bb
create mode 100644 meta/recipes-multimedia/libpng/libpng_1.6.1.bb
diff --git
a/meta/recipes-multimedia/libpng/libpng/0001-configure-lower-automake-requirement.patch
b/meta/recipes-multimedia/libpng/libpng/0001-configure-lower-automake-requirement.patch
new file mode 100644
index 000..34363dc
--- /dev/null
+++
b/meta/recipes-multimedia/libpng/libpng/0001-configure-lower-automake-requirement.patch
@@ -0,0 +1,29 @@
+From a4fd84bdc69e9929a1040f20ea291ee3115bf5b2 Mon Sep 17 00:00:00 2001
+From: Koen Kooi k...@dominion.thruhere.net
+Date: Mon, 15 Apr 2013 11:16:20 +0200
+Subject: [PATCH] configure: lower automake requirement
+
+We're not using parallel tests in OE-core yet
+
+Signed-off-by: Koen Kooi k...@dominion.thruhere.net
+
+Upstream-status: Inapropriate [OE specific build hack]
+---
+ configure.ac | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/configure.ac b/configure.ac
+index 1745d31..7f015fe 100644
+--- a/configure.ac
b/configure.ac
+@@ -27,7 +27,7 @@ AC_CONFIG_MACRO_DIR([scripts])
+ # dist-xz requires automake 1.11 or later
+ # 1.12.2 fixes a security issue in 1.11.2 and 1.12.1
+ # 1.13 is required for parallel tests
+-AM_INIT_AUTOMAKE([1.13 foreign dist-xz color-tests silent-rules])
++AM_INIT_AUTOMAKE([1.12.2 foreign dist-xz color-tests silent-rules])
+ # The following line causes --disable-maintainer-mode to be the default to
+ # configure, this is necessary because libpng distributions cannot rely on the
+ # time stamps of the autotools generated files being correct
+--
+1.8.1.4
diff --git a/meta/recipes-multimedia/libpng/libpng_1.6.0.bb
b/meta/recipes-multimedia/libpng/libpng_1.6.0.bb
deleted file mode 100644
index 951e34a..000
--- a/meta/recipes-multimedia/libpng/libpng_1.6.0.bb
+++ /dev/null
@@ -1,20 +0,0 @@
-SUMMARY = PNG Library
-DESCRIPTION = PNG Library
-HOMEPAGE = http://www.libpng.org/;
-SECTION = libs
-LICENSE = Libpng
-LIC_FILES_CHKSUM = file://LICENSE;md5=03b8ec701cb796c0ec84af22f884edef \
-
file://png.h;beginline=207;endline=321;md5=e829cebefd08488ba5142ea5faea6821
-DEPENDS = zlib
-PR = r0
-LIBV = 16
-
-SRC_URI =
${SOURCEFORGE_MIRROR}/project/libpng/libpng${LIBV}/${PV}/libpng-${PV}.tar.xz \
-
-
-SRC_URI[md5sum] = 3ee623b9a4d33bda7310a5124080b14d
-SRC_URI[sha256sum] =
5e13c31321083b03956b5ff298bacffab7a7ad35c34c122acef314593944b97b
-
-inherit autotools binconfig pkgconfig
-
-BBCLASSEXTEND = native nativesdk
diff --git a/meta/recipes-multimedia/libpng/libpng_1.6.1.bb
b/meta/recipes-multimedia/libpng/libpng_1.6.1.bb
new file mode 100644
index 000..a05e380
--- /dev/null
+++ b/meta/recipes-multimedia/libpng/libpng_1.6.1.bb
@@ -0,0 +1,24 @@
+SUMMARY = PNG Library
+DESCRIPTION = PNG Library
+HOMEPAGE = http://www.libpng.org/;
+SECTION = libs
+LICENSE = Libpng
+LIC_FILES_CHKSUM = file://LICENSE;md5=8273188b2e21c831f5a09fd9285db62f \
+
file://png.h;beginline=207;endline=321;md5=de107fb61766e9d826943f3b6a354fc9 \
+
+DEPENDS = zlib
+PR = r0
+LIBV = 16
+
+SRC_URI =
${SOURCEFORGE_MIRROR}/project/libpng/libpng${LIBV}/${PV}/libpng-${PV}.tar.xz \
+ file://0001-configure-lower-automake-requirement.patch \
+
+
+SRC_URI[md5sum] = 93fc0b0841ce2db0e6756673e22dafc3
+SRC_URI[sha256sum] =
5ef57f8b9ef591c8504e2a8f78d31779f0c8f2b34b34d01d533360d2483c8946
+
+inherit autotools binconfig pkgconfig
+
+EXTRA_OECONF_append_arm = ${@bb.utils.contains(TUNE_FEATURES, neon,
--enable-arm-neon=on, --enable-arm-neon=off, d)}
+
+BBCLASSEXTEND = native nativesdk
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] connman-gnome: Replace broken png files
On Fri, Apr 19, 2013 at 3:12 PM, Emilia Ciobanu
emilia.maria.silvia.ciob...@intel.com wrote:
connman-signal-*.png files were corrupted and this caused
warnings when starting connman-applet.
The patch overwrites the upstream png files.
[YOCTO #4060]
Signed-off-by: Emilia Ciobanu emilia.maria.silvia.ciob...@intel.com
---
.../connman-gnome/images/connman-signal-01.png | Bin 0 - 490 bytes
.../connman-gnome/images/connman-signal-02.png | Bin 0 - 496 bytes
.../connman-gnome/images/connman-signal-03.png | Bin 0 - 492 bytes
.../connman-gnome/images/connman-signal-04.png | Bin 0 - 470 bytes
.../connman-gnome/images/connman-signal-05.png | Bin 0 - 419 bytes
.../connman/connman-gnome_0.7.bb |8 +++-
6 files changed, 7 insertions(+), 1 deletion(-)
create mode 100644
meta/recipes-connectivity/connman/connman-gnome/images/connman-signal-01.png
create mode 100644
meta/recipes-connectivity/connman/connman-gnome/images/connman-signal-02.png
create mode 100644
meta/recipes-connectivity/connman/connman-gnome/images/connman-signal-03.png
create mode 100644
meta/recipes-connectivity/connman/connman-gnome/images/connman-signal-04.png
create mode 100644
meta/recipes-connectivity/connman/connman-gnome/images/connman-signal-05.png
diff --git
a/meta/recipes-connectivity/connman/connman-gnome/images/connman-signal-01.png
b/meta/recipes-connectivity/connman/connman-gnome/images/connman-signal-01.png
new file mode 100644
index
..33247c1e2db4304e48ea0a6145be4de6e420882b
GIT binary patch
literal 490
zcmVG0TupP)h;3K|Lk000e1NJLTq000M000U1^@s6#I$TX6VoOIv0RI60
z0RN!9r;`8x010qNS#tmY3ljhU3ljkVnw%H_000McNliru)Cvt2G}Dr@$)y03CEi
zSad^gZEa4bO1wgWnpwWFU8GbZ8({Xk{QrNlj4iWF9@00B-(L_t(I%k5O5PD4Qu
zoZXqdq)#-6CMbeI5`w`$RU9NZfX`@|AHhTL4hLyM{3F^@J9~;@3_|%O7kEX*6rQx
z?C#9o0{`~gWBGlGk)D-s8f2SC_Q`Xv}bSev!|611l1?clPGbd$hg_;6(~J383i(
zjJw;L+TNu(J~@RV;BK%PxmE@a1vWOfGK`c!=gLfw;loMBP=37cfeMx`0?SshBYua
z4i1k%CQyPkZ=8}X$193Q38T?^L4}|~EQR3oS?%V4r)|smfdY{N*0hNNEGi`9dmK+D
zPiqF$4GiP){A2gNGKDPz@k8RG`0j-N*E4@g)gLt{QDUKrA!4S7zxKxV4q2^p^s
zl(k(AZMpSch6#eDc+!}fZ}1K=-j)yKaK9+n~G{M==dq6ZV*}K?Qs6t+AOD{GaUT
g(S7{`tN4%X6`T(*H@KiqKz%07*qoM6N$g7W0Y-2eap
literal 0
HcmV?d1
diff --git
a/meta/recipes-connectivity/connman/connman-gnome/images/connman-signal-02.png
b/meta/recipes-connectivity/connman/connman-gnome/images/connman-signal-02.png
new file mode 100644
index
..a94fb952ff6cbea25b06c261267fe9a82d77f981
GIT binary patch
literal 496
zcmVM0T2F(P)h;3K|Lk000e1NJLTq000M000U1^@s6#I$TX6VoOIv0RI60
z0RN!9r;`8x010qNS#tmY3ljhU3ljkVnw%H_000McNliru)Cvt2G$Z^+X`%oC03CEi
zSad^gZEa4bO1wgWnpwWFU8GbZ8({Xk{QrNlj4iWF9@00C4L_t(I%k5M#N(4a=
ztnRL!*xlOOfD2LG2a`n287mV(1GD{eYn$7H(q=E52H03YB)SEHT9cOP(@0L|e
z?5tEYpScd2l$WQ4(VAxn#ijflYN;ot{(zAciA;4q)}2BrtBtgg4ud$hg=;E{Bw
z8GzIa7+06)m3yUy|V|pLscLXc6A1JI+m7)8HNlnwa!wsTXzTfS?2CARX{p2zP-7w
zAPEA+#^x5x0*r*DcTLS|jXRoWBnE@ULJER~S#~8C%tO{kLs554|I5NNUAS#Si#WD
z=hOK3;%VVygK)GvyrVt1Imj^UaenNHT{MccX^_hzRa^`^^avlK=`%%HOv#~2aE
zpB5k+(Uj1Olox7^-SE^Go1yOc=kuG-o$BUdz%~WS=9Aj(hY*@YW+(~TlyQ@9
mrlK(Q)1fpIa_UKZ-X`7C)%O7ejFXMNUMnLSTZlN5kg;
literal 0
HcmV?d1
diff --git
a/meta/recipes-connectivity/connman/connman-gnome/images/connman-signal-03.png
b/meta/recipes-connectivity/connman/connman-gnome/images/connman-signal-03.png
new file mode 100644
index
..b5eb405a9009722025c1e93e233f8dec676ff9fd
GIT binary patch
literal 492
zcmVI0Tcd-P)h;3K|Lk000e1NJLTq000M000U1^@s6#I$TX6VoOIv0RI60
z0RN!9r;`8x010qNS#tmY3ljhU3ljkVnw%H_000McNliru)Cvt2GzlmCpmYEL03CEi
zSad^gZEa4bO1wgWnpwWFU8GbZ8({Xk{QrNlj4iWF9@00B@*L_t(I%k5MPQySD
zee+Ar1rSY2glOn}4TK_5AWBYG8dpkLZXPsDL|nv~Yl2Byo0@g7~v`APEN1FxBkX
z^YrGu*#-XNw}U$NPaEf~z|^kHZf~wL0uYICad}nNI|HlraCmgmu6G#y7{HsVfkgns
zPQaMl-(|G2=Jf0wY6fNkHSF3M*wnCp@W+Bdk~hLrD%_C2Gy#~%plAF?Z|jEo@GTo
z9P}a5gQ$YyhoNh#@{gS@#VE9g+gm)sVP{v0JwWT8x}jeOacW2B|R=vF$V-jc0qS
z8-(GY|Ktf%e-o60IMj38IiV-;$iw+=FtOUm{$xA*!Vmq6!iLZ({83@UW=P0a)gX
z+T%h{mV_ZQmu7wn96Tb_Mt66F`8@fDHN9!Vyjf#+Pk;j=@;n7r5!4CFnsuWuwxYcq
iX{`I6{lHWFNAV8gNn5(2{=AIMNUMnLSTYw4$qnZ
literal 0
HcmV?d1
diff --git
a/meta/recipes-connectivity/connman/connman-gnome/images/connman-signal-04.png
b/meta/recipes-connectivity/connman/connman-gnome/images/connman-signal-04.png
new file mode 100644
index
..be54419fa74db126c4039c27566584e5b4d5c26e
GIT binary patch
literal 470
zcmeAS@N?(olHy`uVBq!ia0vp^Vj#@H1|*Mc$*~4fY)RhkE)4%caKYZ?lYt_f1s;*b
z3=G`DAk4@xYmNj^kiEpy*OmPW7q6HxgJ5ExI8aEo#5JPCIX^cyHLrxhxhOTUBsE2$
zJhLQ2AtWPJ!QIn0;C+f}9siTm8Xkih{fr*A%=cO3PA}-wOZSp)I*;d%FUQtb0
zIQ5%BRp@RlGY4yc;z8zjvIU-RVx@$R^98-rQ;=GAei=}va*~9^80yKi15=UuhJ
zxz_HT`?Po%Oxd1`PrvsCFymVg`K7JI{%EnA_rz~vYUTpe~ra^`6Mv??r~~rF@I
Re: [OE-core] [PATCH] gdk-pixbuf: Fix libpng determinism issues
On Fri, 2013-04-19 at 15:41 +0200, Koen Kooi wrote: And would introduce some dependency hell (gtk-doc-native needed for every little gnome thing *and* udev) Nope, that's why gtk-doc-stub exists, and it's already used in OE: http://git.gnome.org/browse/gtk-doc-stub but more importantly it will expose us to that stupid, stupid, stupid practice of using git submodules to drag in autoconf stuff. Correct handling of git submodules is definitely nontrivial. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] connman-gnome: Replace broken png files
Hi Andreas, On 19 April 2013 17:49, Andreas Müller schnitzelt...@googlemail.com wrote: I thought there are efforts for libpng fix ongoing. If not: let me know because meta-gnome's network-manager-applet needs same (seems they use same icons). From the discussion I saw upstream (that I've lost, but it was easy to google) libpng's maintainers consider themselves right, as the files are definitely broken (the breakage occurs due to libpng asking for strict decompression). connman-gnome stole the icons from NM, so you'll certainly want to copy them back into nm-applet. Ross ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] local.conf.sample: Have comments ready to go for quad-core (4 - 8).
All of these solutions assume the user wants to use all of their entire computing resources to do nothing other than their Yocto build. This isn't _always_ the case, is it? :-) Personally, I know this build is going to take time. So I start it, then go off and do other things with my computer. In my case, I don't like it when the other things I'm trying to do on the computer are bogged down due to this all-consuming, background build task. I would much rather that whatever else I'm doing remain responsive to me. Whether the build finishes in 20 minutes or 25 is irrelevant because I'll only notice it's done 30 minutes from now :-) As such I never set my settings to full power... knowingly and purposefully. This being said, I think what is currently in the sample config file (which are roughly half of full power) are good defaults. If you're new to this kind of stuff, these settings will suit just fine. If you're a power user, you'll know how to set them to 8 or 16 or any other setting which suits your needs. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFT] GCC 4.8 recipes
On Apr 2, 2013, at 7:22 AM, Khem Raj raj.k...@gmail.com wrote: Thanks Martin, elfutils test case is now reduced and reported others I will take a look. I have pushed a fix for elfutils issue to the pull branch. please retest and report. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
