[OE-core] [PATCH] build-appliance-image: Updated to wget mixed-up commands fix
Fixes Hob network test failing inside BA. Signed-off-by: Cristian Iorga --- meta/recipes-core/images/build-appliance-image.bb |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/recipes-core/images/build-appliance-image.bb b/meta/recipes-core/images/build-appliance-image.bb index 35c6abe..b89354e 100644 --- a/meta/recipes-core/images/build-appliance-image.bb +++ b/meta/recipes-core/images/build-appliance-image.bb @@ -6,7 +6,7 @@ LICENSE = "MIT" LIC_FILES_CHKSUM = "file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58 \ file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420" -PR = "r17" +PR = "r18" IMAGE_FEATURES += "x11-base package-management splash" @@ -21,7 +21,7 @@ IMAGE_FSTYPES = "vmdk" inherit core-image -SRCREV = "dee77eca39f406f90e60d9c5ef7a66fcc8f57dbf" +SRCREV = "a0cf759537260f00311450e0dac41bf45b474454" SRC_URI = "git://git.yoctoproject.org/poky;protocol=git \ file://Yocto_Build_Appliance.vmx \ file://Yocto_Build_Appliance.vmxf \ -- 1.7.10.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] openssh: CVE-2011-4327
A security flaw was found in the way ssh-keysign, a ssh helper program for host based authentication, attempted to retrieve enough entropy information on configurations that lacked a built-in entropy pool in OpenSSL (a ssh-rand-helper program would be executed to retrieve the entropy from the system environment). A local attacker could use this flaw to obtain unauthorized access to host keys via ptrace(2) process trace attached to the 'ssh-rand-helper' program. https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2011-4327 http://www.openssh.com/txt/portable-keysign-rand-helper.adv [YOCTO #3493] Signed-off-by: Li Wang --- .../openssh-6.0p1/openssh-CVE-2011-4327.patch | 27 ++ meta/recipes-connectivity/openssh/openssh_6.0p1.bb | 3 ++- 2 files changed, 29 insertions(+), 1 deletion(-) create mode 100644 meta/recipes-connectivity/openssh/openssh-6.0p1/openssh-CVE-2011-4327.patch diff --git a/meta/recipes-connectivity/openssh/openssh-6.0p1/openssh-CVE-2011-4327.patch b/meta/recipes-connectivity/openssh/openssh-6.0p1/openssh-CVE-2011-4327.patch new file mode 100644 index 000..8489edc --- /dev/null +++ b/meta/recipes-connectivity/openssh/openssh-6.0p1/openssh-CVE-2011-4327.patch @@ -0,0 +1,27 @@ +openssh-CVE-2011-4327 + +A security flaw was found in the way ssh-keysign, +a ssh helper program for host based authentication, +attempted to retrieve enough entropy information on configurations that +lacked a built-in entropy pool in OpenSSL (a ssh-rand-helper program would +be executed to retrieve the entropy from the system environment). +A local attacker could use this flaw to obtain unauthorized access to host keys +via ptrace(2) process trace attached to the 'ssh-rand-helper' program. + +https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2011-4327 +http://www.openssh.com/txt/portable-keysign-rand-helper.adv + +Signed-off-by: Li Wang +--- a/ssh-keysign.c b/ssh-keysign.c +@@ -170,6 +170,10 @@ + key_fd[i++] = open(_PATH_HOST_DSA_KEY_FILE, O_RDONLY); + key_fd[i++] = open(_PATH_HOST_ECDSA_KEY_FILE, O_RDONLY); + key_fd[i++] = open(_PATH_HOST_RSA_KEY_FILE, O_RDONLY); ++ if (fcntl(key_fd[0], F_SETFD, FD_CLOEXEC) != 0 || ++ fcntl(key_fd[1], F_SETFD, FD_CLOEXEC) != 0 || ++ fcntl(key_fd[2], F_SETFD, FD_CLOEXEC) != 0) ++ fatal("fcntl failed"); + + original_real_uid = getuid(); /* XXX readconf.c needs this */ + if ((pw = getpwuid(original_real_uid)) == NULL) diff --git a/meta/recipes-connectivity/openssh/openssh_6.0p1.bb b/meta/recipes-connectivity/openssh/openssh_6.0p1.bb index 31202d4..df77040 100644 --- a/meta/recipes-connectivity/openssh/openssh_6.0p1.bb +++ b/meta/recipes-connectivity/openssh/openssh_6.0p1.bb @@ -7,7 +7,7 @@ SECTION = "console/network" LICENSE = "BSD" LIC_FILES_CHKSUM = "file://LICENCE;md5=e326045657e842541d3f35aada442507" -PR = "r3" +PR = "r4" DEPENDS = "zlib openssl" DEPENDS += "${@base_contains('DISTRO_FEATURES', 'pam', 'libpam', '', d)}" @@ -23,6 +23,7 @@ SRC_URI = "ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-${PV}.tar. file://sshd_config \ file://ssh_config \ file://init \ + file://openssh-CVE-2011-4327.patch \ ${@base_contains('DISTRO_FEATURES', 'pam', '${PAM_SRC_URI}', '', d)}" PAM_SRC_URI = "file://sshd" -- 1.7.11 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libpng: update to upstream version 1.2.50
On Tue, 2012-11-27 at 05:18 +0200, Marko Lindqvist wrote: > Signed-off-by: Marko Lindqvist What changed in the LICENSE? We try and mention this in the commit message... Cheers, Richard > --- > .../libpng/{libpng_1.2.49.bb => libpng_1.2.50.bb} | 12 > ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) > rename meta/recipes-multimedia/libpng/{libpng_1.2.49.bb => libpng_1.2.50.bb} > (52%) > > diff --git a/meta/recipes-multimedia/libpng/libpng_1.2.49.bb > b/meta/recipes-multimedia/libpng/libpng_1.2.50.bb > similarity index 52% > rename from meta/recipes-multimedia/libpng/libpng_1.2.49.bb > rename to meta/recipes-multimedia/libpng/libpng_1.2.50.bb > index d33a9f5..211e357 100644 > --- a/meta/recipes-multimedia/libpng/libpng_1.2.49.bb > +++ b/meta/recipes-multimedia/libpng/libpng_1.2.50.bb > @@ -3,15 +3,15 @@ DESCRIPTION = "PNG Library" > HOMEPAGE = "http://www.libpng.org/"; > SECTION = "libs" > LICENSE = "Libpng" > -LIC_FILES_CHKSUM = "file://LICENSE;md5=20110633230abd47fe8680afa75f1492 \ > - > file://png.h;startline=308;endline=422;md5=edd1c552386a8c3773d90e278ae30891" > +LIC_FILES_CHKSUM = "file://LICENSE;md5=c3d807a85c09ebdff087f18b4969ff96 \ > + > file://png.h;startline=310;endline=424;md5=62968b88b0425ceeb919de3fd21b03e5" > DEPENDS = "zlib" > -PR = "r1" > +PR = "r0" > > -SRC_URI = > "${SOURCEFORGE_MIRROR}/project/libpng/libpng12/${PV}/libpng-${PV}.tar.bz2" > +SRC_URI = > "${SOURCEFORGE_MIRROR}/project/libpng/libpng12/${PV}/libpng-${PV}.tar.xz" > > -SRC_URI[md5sum] = "d5106b70b4f8b464a7da66bffe4565fb" > -SRC_URI[sha256sum] = > "fbf8faa70ebca2ed2ee6df6f2249f4722517b581af5b6c3c71bbdaf925d5954e" > +SRC_URI[md5sum] = "a3e00fccbfe356174ab515b5c00641c7" > +SRC_URI[sha256sum] = > "4724f81f8c92ac7f360ad1fbf173396ea7c535923424db9fbaff07bfd9d8e8e7" > > inherit autotools binconfig pkgconfig > ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libpng: update to upstream version 1.2.50
On 27 November 2012 10:54, Richard Purdie wrote: > On Tue, 2012-11-27 at 05:18 +0200, Marko Lindqvist wrote: >> Signed-off-by: Marko Lindqvist > > What changed in the LICENSE? Version number and release date. > > Cheers, > > Richard > > >> --- >> .../libpng/{libpng_1.2.49.bb => libpng_1.2.50.bb} | 12 >> ++-- >> 1 file changed, 6 insertions(+), 6 deletions(-) >> rename meta/recipes-multimedia/libpng/{libpng_1.2.49.bb => >> libpng_1.2.50.bb} (52%) >> >> diff --git a/meta/recipes-multimedia/libpng/libpng_1.2.49.bb >> b/meta/recipes-multimedia/libpng/libpng_1.2.50.bb >> similarity index 52% >> rename from meta/recipes-multimedia/libpng/libpng_1.2.49.bb >> rename to meta/recipes-multimedia/libpng/libpng_1.2.50.bb >> index d33a9f5..211e357 100644 >> --- a/meta/recipes-multimedia/libpng/libpng_1.2.49.bb >> +++ b/meta/recipes-multimedia/libpng/libpng_1.2.50.bb >> @@ -3,15 +3,15 @@ DESCRIPTION = "PNG Library" >> HOMEPAGE = "http://www.libpng.org/"; >> SECTION = "libs" >> LICENSE = "Libpng" >> -LIC_FILES_CHKSUM = "file://LICENSE;md5=20110633230abd47fe8680afa75f1492 \ >> - >> file://png.h;startline=308;endline=422;md5=edd1c552386a8c3773d90e278ae30891" >> +LIC_FILES_CHKSUM = "file://LICENSE;md5=c3d807a85c09ebdff087f18b4969ff96 \ >> + >> file://png.h;startline=310;endline=424;md5=62968b88b0425ceeb919de3fd21b03e5" >> DEPENDS = "zlib" >> -PR = "r1" >> +PR = "r0" >> >> -SRC_URI = >> "${SOURCEFORGE_MIRROR}/project/libpng/libpng12/${PV}/libpng-${PV}.tar.bz2" >> +SRC_URI = >> "${SOURCEFORGE_MIRROR}/project/libpng/libpng12/${PV}/libpng-${PV}.tar.xz" >> >> -SRC_URI[md5sum] = "d5106b70b4f8b464a7da66bffe4565fb" >> -SRC_URI[sha256sum] = >> "fbf8faa70ebca2ed2ee6df6f2249f4722517b581af5b6c3c71bbdaf925d5954e" >> +SRC_URI[md5sum] = "a3e00fccbfe356174ab515b5c00641c7" >> +SRC_URI[sha256sum] = >> "4724f81f8c92ac7f360ad1fbf173396ea7c535923424db9fbaff07bfd9d8e8e7" >> >> inherit autotools binconfig pkgconfig >> > > ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] gtk+: do not prelight GtkButton in touchscreen mode
Signed-off-by: Andreas Müller --- ...utton-do-not-prelight-in-touchscreen-mode.patch | 48 meta/recipes-gnome/gtk+/gtk+_2.24.13.bb|3 +- 2 files changed, 50 insertions(+), 1 deletions(-) create mode 100644 meta/recipes-gnome/gtk+/gtk+-2.24.13/0001-GtkButton-do-not-prelight-in-touchscreen-mode.patch diff --git a/meta/recipes-gnome/gtk+/gtk+-2.24.13/0001-GtkButton-do-not-prelight-in-touchscreen-mode.patch b/meta/recipes-gnome/gtk+/gtk+-2.24.13/0001-GtkButton-do-not-prelight-in-touchscreen-mode.patch new file mode 100644 index 000..671fd2f --- /dev/null +++ b/meta/recipes-gnome/gtk+/gtk+-2.24.13/0001-GtkButton-do-not-prelight-in-touchscreen-mode.patch @@ -0,0 +1,48 @@ +From d1f7a894674dfdd6769f1bbae31eb1a69e451a5c Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Andreas=20M=C3=BCller?= +Date: Fri, 16 Nov 2012 22:07:28 +0100 +Subject: [PATCH] GtkButton: do not prelight in touchscreen mode +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +Code was copied from GtkToggleButton. + +Upstream-status: pending [1] + +https://bugzilla.gnome.org/show_bug.cgi?id=689138 + +Signed-off-by: Andreas Müller +--- + gtk/gtkbutton.c |8 ++-- + 1 files changed, 6 insertions(+), 2 deletions(-) + +diff --git a/gtk/gtkbutton.c b/gtk/gtkbutton.c +index f472007..1beb1b6 100644 +--- a/gtk/gtkbutton.c b/gtk/gtkbutton.c +@@ -2079,15 +2079,19 @@ _gtk_button_set_depressed (GtkButton *button, + static void + gtk_button_update_state (GtkButton *button) + { +- gboolean depressed; ++ gboolean depressed, touchscreen; + GtkStateType new_state; + ++ g_object_get (gtk_widget_get_settings (GTK_WIDGET (button)), ++"gtk-touchscreen-mode", &touchscreen, ++NULL); ++ + if (button->activate_timeout) + depressed = button->depress_on_activate; + else + depressed = button->in_button && button->button_down; + +- if (button->in_button && (!button->button_down || !depressed)) ++ if (!touchscreen && button->in_button && (!button->button_down || !depressed)) + new_state = GTK_STATE_PRELIGHT; + else + new_state = depressed ? GTK_STATE_ACTIVE : GTK_STATE_NORMAL; +-- +1.7.6.5 + diff --git a/meta/recipes-gnome/gtk+/gtk+_2.24.13.bb b/meta/recipes-gnome/gtk+/gtk+_2.24.13.bb index b358b7f..bc88284 100644 --- a/meta/recipes-gnome/gtk+/gtk+_2.24.13.bb +++ b/meta/recipes-gnome/gtk+/gtk+_2.24.13.bb @@ -13,6 +13,7 @@ SRC_URI = "http://download.gnome.org/sources/gtk+/2.24/gtk+-${PV}.tar.xz \ file://toggle-font.diff;striplevel=0 \ file://0001-bgo-584832-Duplicate-the-exec-string-returned-by-gtk.patch \ file://doc-fixes.patch \ + file://0001-GtkButton-do-not-prelight-in-touchscreen-mode.patch \ " # TO MERGE @@ -27,7 +28,7 @@ SRC_URI = "http://download.gnome.org/sources/gtk+/2.24/gtk+-${PV}.tar.xz \ #file://combo-arrow-size.patch;striplevel=0 #file://configurefix.patch -PR = "r1" +PR = "r2" SRC_URI[md5sum] = "e949406751df51e1e40e85628005a069" SRC_URI[sha256sum] = "35e1a01e46b02970b02ee9f299390d0aa57c1215ad2667bcd584b72f4ea6513d" -- 1.7.6.5 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gtk+: do not prelight GtkButton in touchscreen mode
On 27 November 2012 09:18, Andreas Müller wrote: > Signed-off-by: Andreas Müller Signed-off-by: Ross Burton Ross ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] qemuarm: configure of bison fails, claims to need flex
trying to build absolutely stock qemuarm image with current oe-core, got: ERROR: Task 800 (virtual:native:/home/rpjday/OE/dist/layers/oe-core/meta/recipes-devtools/bison/bison_2.5.1.bb, do_configure) failed with exit code '1' and the log file claimed that bison needed flex. i'm doing it all over again from scratch just to make sure it wasn't something silly i did, i'll report back if i can reproduce it. 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] qemuarm: configure of bison fails, claims to need flex [SOLVED?]
On Tue, 27 Nov 2012, Robert P. J. Day wrote: > > trying to build absolutely stock qemuarm image with current oe-core, > got: > > ERROR: Task 800 > (virtual:native:/home/rpjday/OE/dist/layers/oe-core/meta/recipes-devtools/bison/bison_2.5.1.bb, > do_configure) failed with exit code '1' > > and the log file claimed that bison needed flex. i'm doing it all > over again from scratch just to make sure it wasn't something silly > i did, i'll report back if i can reproduce it. ah, i see where i did something unapproved -- to test what i could add to the ASSUME_PROVIDED list, i added this to my local.conf: ASSUME_PROVIDED += "m4 quilt" which caused the configure step for bison to fail, claiming that it needed flex. should i have expected that? am i misunderstanding the rationale for ASSUME_PROVIDED? rday p.s. just restricted to ASSUME_PROVIDED to "m4", that appears to be causing the problem. -- 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
[OE-core] [PATCH] subversion: update to 1.7.7
- fix WARNING: Failed to fetch URL http://www.apache.org/dist/subversion/subversion-1.7.6.tar.bz2 - subversion-1.7.6_mod_dontdothat_svnserve_only.patch doesn't seems to be useful, cc Marcin to get confirmation Signed-off-by: Eric Bénard Cc: Marcin Juszkiewicz --- ...ersion-1.7.6_mod_dontdothat_svnserve_only.patch | 109 .../fix-install-depends.patch |0 .../libtool2.patch |0 .../{subversion_1.7.6.bb => subversion_1.7.7.bb} |5 +- 4 files changed, 2 insertions(+), 112 deletions(-) delete mode 100644 meta/recipes-devtools/subversion/subversion-1.7.6/subversion-1.7.6_mod_dontdothat_svnserve_only.patch rename meta/recipes-devtools/subversion/{subversion-1.7.6 => subversion-1.7.7}/fix-install-depends.patch (100%) rename meta/recipes-devtools/subversion/{subversion-1.7.6 => subversion-1.7.7}/libtool2.patch (100%) rename meta/recipes-devtools/subversion/{subversion_1.7.6.bb => subversion_1.7.7.bb} (83%) diff --git a/meta/recipes-devtools/subversion/subversion-1.7.6/subversion-1.7.6_mod_dontdothat_svnserve_only.patch b/meta/recipes-devtools/subversion/subversion-1.7.6/subversion-1.7.6_mod_dontdothat_svnserve_only.patch deleted file mode 100644 index ad3e767..000 --- a/meta/recipes-devtools/subversion/subversion-1.7.6/subversion-1.7.6_mod_dontdothat_svnserve_only.patch +++ /dev/null @@ -1,109 +0,0 @@ -Patch taken from subversion-users ML. - -From: Roman Plessl -Date: Thu, 16 Aug 2012 09:48:32 +0200 (CEST) - -Hi All, -I try to compile and installe the new subversion 1.7.6 using my build -system. I use svnserve as standalone subversion server so my build -is not using the apache bindings. -I got the following compile error for the module mod_dontdothat: -... -/bin/bash /scratch/build/subversion-1.7.6-rp/subversion-1.7.6/libtool ---tag=CC --silent --mode=compile gcc --I/usr/pack/subversion-1.7.6-rp/include -DLINUX=2 -D_REENTRANT --D_GNU_SOURCE -g -O2 -g -O2 -pthread --Werror=implicit-function-declaration -I./subversion/include --I./subversion -I/usr/pack/subversion-1.7.6-rp/include/apr-1 --I/usr/pack/subversion-1.7.6-rp/include/apr-1 --I/usr/pack/subversion-1.7.6-rp/include --I/usr/pack/subversion-1.7.6-rp/include/neon --I/usr/pack/subversion-1.7.6-rp/include/serf-1 -o -tools/server-side/mod_dontdothat/mod_dontdothat.lo -c -tools/server-side/mod_dontdothat/mod_dontdothat.c -tools/server-side/mod_dontdothat/mod_dontdothat.c:25:19: error: httpd.h: -No such file or directory -tools/server-side/mod_dontdothat/mod_dontdothat.c:26:25: error: -http_config.h: No such file or directory -tools/server-side/mod_dontdothat/mod_dontdothat.c:27:27: error: -http_protocol.h: No such file or directory -tools/server-side/mod_dontdothat/mod_dontdothat.c:28:26: error: -http_request.h: No such file or directory -tools/server-side/mod_dontdothat/mod_dontdothat.c:29:22: error: -http_log.h: No such file or directory -tools/server-side/mod_dontdothat/mod_dontdothat.c:30:25: error: -util_filter.h: No such file or directory -tools/server-side/mod_dontdothat/mod_dontdothat.c:31:23: error: -ap_config.h: No such file or directory -... -I suppose the module mod_dontdothat should be only build with activated -'apache-mod's . Maybe the build target declaration has been forget when -moving the target for subversion 1.7.6. -... -checking for Apache module support via DSO through APXS... no -== -WARNING: skipping the build of mod_dav_svn - try using --with-apxs -== -... -Could you check that? -I have used the attached patch to fix it for myself. -Cheers -Roman --- -Roman Plesslphone:+41 (62) 775 9904 -OETIKER+PARTNER AG email:roman.plessl_at_oetiker.ch -Aarweg 15 web: http://it.oetiker.ch -CH-4600 Olten switch board: +41 (62) 775 9900 - - -Upstream-Status: Backport [from ML] - - build-outputs.mk |4 ++-- - build.conf |2 +- - 2 files changed, 3 insertions(+), 3 deletions(-) - subversion-1.7.6.orig/build-outputs.mk -+++ subversion-1.7.6/build-outputs.mk -@@ -823,11 +823,11 @@ subversion/tests/libsvn_delta/window-tes - - - # Section 6: Install-Group build targets - - --apache-mod: subversion/mod_authz_svn/mod_authz_svn.la subversion/mod_dav_svn/mod_dav_svn.la -+apache-mod: subversion/mod_authz_svn/mod_authz_svn.la subversion/mod_dav_svn/mod_dav_svn.la tools/server-side/mod_dontdothat/mod_dontdothat.la - - bdb-lib: subversion/libsvn_fs_base/libsvn_fs_base-1.la - - bdb-test: subversion/tests/libsvn_fs_base/changes-test$(EXEEXT) subversion/tests/libsvn_fs_base/fs-base-test$(EXEEXT) subversion/tests/libsvn_fs_base/strings-reps-test$(EXEEXT) - -@@ -875,11 +875,11 @@ swig-rb: subversion/bin
Re: [OE-core] [PATCH] subversion: update to 1.7.7
W dniu 27.11.2012 11:24, Eric Bénard pisze: > - fix WARNING: Failed to fetch URL > http://www.apache.org/dist/subversion/subversion-1.7.6.tar.bz2 > - subversion-1.7.6_mod_dontdothat_svnserve_only.patch doesn't seems to be > useful, > cc Marcin to get confirmation > > Signed-off-by: Eric Bénard > Cc: Marcin Juszkiewicz As long as it builds I am fine. 1.7.6 required that patch to get built. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] initramfs-framework: udev: Handle alternative binary paths
This allows use of udev daemon for different installation destinations so allowing use of udev's from systemd code for initramfs. Signed-off-by: Otavio Salvador --- .../initrdscripts/initramfs-framework/udev | 25 .../initrdscripts/initramfs-framework_1.0.bb |2 +- 2 files changed, 21 insertions(+), 6 deletions(-) diff --git a/meta/recipes-core/initrdscripts/initramfs-framework/udev b/meta/recipes-core/initrdscripts/initramfs-framework/udev index 15a1d5b..7fbcc61 100644 --- a/meta/recipes-core/initrdscripts/initramfs-framework/udev +++ b/meta/recipes-core/initrdscripts/initramfs-framework/udev @@ -1,10 +1,25 @@ #!/bin/sh -# Copyright (C) 2011 O.S. Systems Software LTDA. +# Copyright (C) 2011, 2012 O.S. Systems Software LTDA. # Licensed on MIT +udev_daemon() { + OPTIONS="/sbin/udevd /lib/udev/udevd /lib/systemd/systemd-udevd" + + for o in $OPTIONS; do + if [ -x "$o" ]; then + echo $o + return 0 + fi + done + + return 1 +} + +_UDEV_DAEMON=`udev_daemon` + udev_enabled() { - if [ ! -e /lib/udev/udevd ]; then - debug "/lib/udev/udev doesn't exist" + if [ -z "$_UDEV_DAEMON" ]; then + msg "WARNING: Cannot find the udev daemon; daemon will not be started in initramfs." return 1 fi @@ -14,9 +29,9 @@ udev_enabled() { udev_run() { mkdir -p /run - /lib/udev/udevd --daemon > /dev/null + $_UDEV_DAEMON --daemon udevadm trigger --action=add udevadm settle - killall udevd 2>/dev/null + killall `basename $_UDEV_DAEMON` 2>/dev/null } diff --git a/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb b/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb index 45d6592..cbb4a39 100644 --- a/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb +++ b/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb @@ -3,7 +3,7 @@ LICENSE = "MIT" LIC_FILES_CHKSUM = "file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420" RDEPENDS = "busybox" -PR = "r1" +PR = "r2" inherit allarch -- 1.7.10.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] initramfs-framework: init: Stop mount warnings during boot
For a completely quiet boot using recent versions of utilities, the /etc/fstab and /var/lock need to be available. Signed-off-by: Otavio Salvador --- meta/recipes-core/initrdscripts/initramfs-framework/init |7 +-- meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb |2 +- 2 files changed, 6 insertions(+), 3 deletions(-) diff --git a/meta/recipes-core/initrdscripts/initramfs-framework/init b/meta/recipes-core/initrdscripts/initramfs-framework/init index fc4b0db..0be8f4d 100755 --- a/meta/recipes-core/initrdscripts/initramfs-framework/init +++ b/meta/recipes-core/initrdscripts/initramfs-framework/init @@ -68,8 +68,11 @@ MODULE_PRE_HOOKS="" # functions to call before running each module MODULE_POST_HOOKS="" # functions to call after running each module MODULES_DIR=/init.d # place to look for modules -# initialize /proc and /sys -mkdir -p /proc /sys +# make mount stop complaining about missing /etc/fstab +touch /etc/fstab + +# initialize /proc, /sys and /var/lock +mkdir -p /proc /sys /var/lock mount -t proc proc /proc mount -t sysfs sysfs /sys diff --git a/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb b/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb index cbb4a39..fac356c 100644 --- a/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb +++ b/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb @@ -3,7 +3,7 @@ LICENSE = "MIT" LIC_FILES_CHKSUM = "file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420" RDEPENDS = "busybox" -PR = "r2" +PR = "r3" inherit allarch -- 1.7.10.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [for-danny][PATCH 1/3] initrdscripts: fix udevd in the live boot init scripts
From: Ross Burton udevd moved location and isn't in $PATH anymore, so use an absolute path to start it. The control socket path moved too, so mkdir the directory it's in. Mounts the new devtmpfs on /dev device tree. Signed-off-by: Ross Burton Signed-off-by: Alexandru Damian Signed-off-by: Richard Purdie --- meta/recipes-core/initrdscripts/files/init-live.sh |4 +++- meta/recipes-core/initrdscripts/initramfs-framework/udev |6 +++--- meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb |2 ++ meta/recipes-core/initrdscripts/initramfs-live-boot_1.0.bb |2 +- 4 files changed, 9 insertions(+), 5 deletions(-) diff --git a/meta/recipes-core/initrdscripts/files/init-live.sh b/meta/recipes-core/initrdscripts/files/init-live.sh index 5682fd1..c591f0d 100644 --- a/meta/recipes-core/initrdscripts/files/init-live.sh +++ b/meta/recipes-core/initrdscripts/files/init-live.sh @@ -14,12 +14,14 @@ early_setup() { mkdir -p /sys mount -t proc proc /proc mount -t sysfs sysfs /sys +mount -t devtmpfs none /dev # support modular kernel modprobe isofs 2> /dev/null mkdir -p /run -udevd --daemon +mkdir -p /var/run +/lib/udev/udevd --daemon udevadm trigger --action=add } diff --git a/meta/recipes-core/initrdscripts/initramfs-framework/udev b/meta/recipes-core/initrdscripts/initramfs-framework/udev index 9ea8aa3..15a1d5b 100644 --- a/meta/recipes-core/initrdscripts/initramfs-framework/udev +++ b/meta/recipes-core/initrdscripts/initramfs-framework/udev @@ -3,8 +3,8 @@ # Licensed on MIT udev_enabled() { - if [ ! -e /sbin/udevd ]; then - debug "/sbin/udev doesn't exist" + if [ ! -e /lib/udev/udevd ]; then + debug "/lib/udev/udev doesn't exist" return 1 fi @@ -14,7 +14,7 @@ udev_enabled() { udev_run() { mkdir -p /run - udevd --daemon > /dev/null + /lib/udev/udevd --daemon > /dev/null udevadm trigger --action=add udevadm settle diff --git a/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb b/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb index 58e41d4..45d6592 100644 --- a/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb +++ b/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb @@ -3,6 +3,8 @@ LICENSE = "MIT" LIC_FILES_CHKSUM = "file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420" RDEPENDS = "busybox" +PR = "r1" + inherit allarch SRC_URI = "file://init \ diff --git a/meta/recipes-core/initrdscripts/initramfs-live-boot_1.0.bb b/meta/recipes-core/initrdscripts/initramfs-live-boot_1.0.bb index 137a401..55a8600 100644 --- a/meta/recipes-core/initrdscripts/initramfs-live-boot_1.0.bb +++ b/meta/recipes-core/initrdscripts/initramfs-live-boot_1.0.bb @@ -5,7 +5,7 @@ RDEPENDS = "udev" DEPENDS = "virtual/kernel" SRC_URI = "file://init-live.sh" -PR = "r10" +PR = "r11" do_compile() { #if grep -q "CONFIG_UNION_FS=y" ${STAGING_KERNEL_DIR}/.config; then -- 1.7.10.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [for-danny][PATCH 2/3] initramfs-framework: udev: Handle alternative binary paths
This allows use of udev daemon for different installation destinations so allowing use of udev's from systemd code for initramfs. Signed-off-by: Otavio Salvador --- .../initrdscripts/initramfs-framework/udev | 25 .../initrdscripts/initramfs-framework_1.0.bb |2 +- 2 files changed, 21 insertions(+), 6 deletions(-) diff --git a/meta/recipes-core/initrdscripts/initramfs-framework/udev b/meta/recipes-core/initrdscripts/initramfs-framework/udev index 15a1d5b..7fbcc61 100644 --- a/meta/recipes-core/initrdscripts/initramfs-framework/udev +++ b/meta/recipes-core/initrdscripts/initramfs-framework/udev @@ -1,10 +1,25 @@ #!/bin/sh -# Copyright (C) 2011 O.S. Systems Software LTDA. +# Copyright (C) 2011, 2012 O.S. Systems Software LTDA. # Licensed on MIT +udev_daemon() { + OPTIONS="/sbin/udevd /lib/udev/udevd /lib/systemd/systemd-udevd" + + for o in $OPTIONS; do + if [ -x "$o" ]; then + echo $o + return 0 + fi + done + + return 1 +} + +_UDEV_DAEMON=`udev_daemon` + udev_enabled() { - if [ ! -e /lib/udev/udevd ]; then - debug "/lib/udev/udev doesn't exist" + if [ -z "$_UDEV_DAEMON" ]; then + msg "WARNING: Cannot find the udev daemon; daemon will not be started in initramfs." return 1 fi @@ -14,9 +29,9 @@ udev_enabled() { udev_run() { mkdir -p /run - /lib/udev/udevd --daemon > /dev/null + $_UDEV_DAEMON --daemon udevadm trigger --action=add udevadm settle - killall udevd 2>/dev/null + killall `basename $_UDEV_DAEMON` 2>/dev/null } diff --git a/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb b/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb index 45d6592..cbb4a39 100644 --- a/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb +++ b/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb @@ -3,7 +3,7 @@ LICENSE = "MIT" LIC_FILES_CHKSUM = "file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420" RDEPENDS = "busybox" -PR = "r1" +PR = "r2" inherit allarch -- 1.7.10.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [for-danny][PATCH 3/3] initramfs-framework: init: Stop mount warnings during boot
For a completely quiet boot using recent versions of utilities, the /etc/fstab and /var/lock need to be available. Signed-off-by: Otavio Salvador --- meta/recipes-core/initrdscripts/initramfs-framework/init |7 +-- meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb |2 +- 2 files changed, 6 insertions(+), 3 deletions(-) diff --git a/meta/recipes-core/initrdscripts/initramfs-framework/init b/meta/recipes-core/initrdscripts/initramfs-framework/init index fc4b0db..0be8f4d 100755 --- a/meta/recipes-core/initrdscripts/initramfs-framework/init +++ b/meta/recipes-core/initrdscripts/initramfs-framework/init @@ -68,8 +68,11 @@ MODULE_PRE_HOOKS="" # functions to call before running each module MODULE_POST_HOOKS="" # functions to call after running each module MODULES_DIR=/init.d # place to look for modules -# initialize /proc and /sys -mkdir -p /proc /sys +# make mount stop complaining about missing /etc/fstab +touch /etc/fstab + +# initialize /proc, /sys and /var/lock +mkdir -p /proc /sys /var/lock mount -t proc proc /proc mount -t sysfs sysfs /sys diff --git a/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb b/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb index cbb4a39..fac356c 100644 --- a/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb +++ b/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb @@ -3,7 +3,7 @@ LICENSE = "MIT" LIC_FILES_CHKSUM = "file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420" RDEPENDS = "busybox" -PR = "r2" +PR = "r3" inherit allarch -- 1.7.10.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] udev 182: Create a symlink of /lib/udev/udevd in /sbin
From: Muhammad Shakeel >From udev 174 changelog: "The udev daemon moved to /lib/udev/udevd. Non-systemd init systems and non-dracut initramfs image generators need to change the init scripts. Alternatively the udev build needs to move udevd back to /sbin or create a symlink in /sbin, which is not done by default." Also for 64 bit architectures there exists /lib64/udev instead of /lib/udev and current init script fails to start udev. Signed-off-by: Muhammad Shakeel --- meta/recipes-core/udev/udev.inc|4 meta/recipes-core/udev/udev/init |4 ++-- meta/recipes-core/udev/udev_182.bb |2 +- 3 files changed, 7 insertions(+), 3 deletions(-) diff --git a/meta/recipes-core/udev/udev.inc b/meta/recipes-core/udev/udev.inc index 4705b9b..a882efe 100644 --- a/meta/recipes-core/udev/udev.inc +++ b/meta/recipes-core/udev/udev.inc @@ -96,5 +96,9 @@ do_install_append () { # hid2hci has moved to bluez4. removed in udev as of version 169 rm -f ${D}${base_libdir}/udev/hid2hci +# Create a symlink of /lib/udev/udevd in /sbin +install -d ${D}${base_sbindir} +ln -s ..${base_libdir}/udev/udevd ${D}${base_sbindir}/udevd + echo 'udev_run="/var/run/udev"' >> ${D}${sysconfdir}/udev/udev.conf } diff --git a/meta/recipes-core/udev/udev/init b/meta/recipes-core/udev/udev/init index 74449fe..84631ac 100644 --- a/meta/recipes-core/udev/udev/init +++ b/meta/recipes-core/udev/udev/init @@ -13,7 +13,7 @@ export TZ=/etc/localtime [ -d /sys/class ] || exit 1 [ -r /proc/mounts ] || exit 1 -[ -x /lib/udev/udevd ] || exit 1 +[ -x /sbin/udevd ] || exit 1 [ -f /etc/default/udev-cache ] && . /etc/default/udev-cache [ -f /etc/udev/udev.conf ] && . /etc/udev/udev.conf @@ -69,7 +69,7 @@ kill_udevd > "/dev/null" 2>&1 # trigger the sorted events echo -e '\000\000\000\000' > /proc/sys/kernel/hotplug -/lib/udev/udevd -d +/sbin/udevd -d /usr/bin/udevadm control --env=STARTUP=1 if [ "$not_first_boot" != "" ];then diff --git a/meta/recipes-core/udev/udev_182.bb b/meta/recipes-core/udev/udev_182.bb index c41de9f..0ae9f8c 100644 --- a/meta/recipes-core/udev/udev_182.bb +++ b/meta/recipes-core/udev/udev_182.bb @@ -1,6 +1,6 @@ include udev.inc -PR = "r2" +PR = "r3" # module-init-tools from kmod_git will provide libkmod runtime DEPENDS += "module-init-tools" -- 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] udev 182: Create a symlink of /lib/udev/udevd in /sbin
On Tue, Nov 27, 2012 at 10:57 AM, Shakeel, Muhammad wrote: > From: Muhammad Shakeel > > From udev 174 changelog: > "The udev daemon moved to /lib/udev/udevd. Non-systemd init systems > and non-dracut initramfs image generators need to change the init > scripts. Alternatively the udev build needs to move udevd back to > /sbin or create a symlink in /sbin, which is not done by default." > > Also for 64 bit architectures there exists /lib64/udev instead of > /lib/udev and current init script fails to start udev. > > Signed-off-by: Muhammad Shakeel As far as I know, all code in master now handles it properly (the missing bits I sent a patch today) so why to include this symlink? -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] qemuarm: configure of bison fails, claims to need flex [SOLVED?]
On Tue, Nov 27, 2012 at 3:19 AM, Robert P. J. Day wrote: > On Tue, 27 Nov 2012, Robert P. J. Day wrote: > > > > > trying to build absolutely stock qemuarm image with current oe-core, > > got: > > > > ERROR: Task 800 > > > (virtual:native:/home/rpjday/OE/dist/layers/oe-core/meta/recipes-devtools/bison/ > bison_2.5.1.bb, > > do_configure) failed with exit code '1' > > > > and the log file claimed that bison needed flex. i'm doing it all > > over again from scratch just to make sure it wasn't something silly > > i did, i'll report back if i can reproduce it. > > ah, i see where i did something unapproved -- to test what i could > add to the ASSUME_PROVIDED list, i added this to my local.conf: > > ASSUME_PROVIDED += "m4 quilt" > > which caused the configure step for bison to fail, claiming that it > needed flex. should i have expected that? am i misunderstanding the > rationale for ASSUME_PROVIDED? > First of all, if you want to do that, you should be adding m4-native and quilt-native to ASSUME_PROVIDED, not m4 and quilt, unless your build machine somehow has cross-compiled stuff already ;) -- Christopher Larson ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] qemuarm: configure of bison fails, claims to need flex [SOLVED?]
On Tue, 2012-11-27 at 05:19 -0500, Robert P. J. Day wrote: > On Tue, 27 Nov 2012, Robert P. J. Day wrote: > > > > > trying to build absolutely stock qemuarm image with current oe-core, > > got: > > > > ERROR: Task 800 > > (virtual:native:/home/rpjday/OE/dist/layers/oe-core/meta/recipes-devtools/bison/bison_2.5.1.bb, > > do_configure) failed with exit code '1' > > > > and the log file claimed that bison needed flex. i'm doing it all > > over again from scratch just to make sure it wasn't something silly > > i did, i'll report back if i can reproduce it. > > ah, i see where i did something unapproved -- to test what i could > add to the ASSUME_PROVIDED list, i added this to my local.conf: > > ASSUME_PROVIDED += "m4 quilt" > > which caused the configure step for bison to fail, claiming that it > needed flex. should i have expected that? am i misunderstanding the > rationale for ASSUME_PROVIDED? You are misunderstanding the syntax. Were you not meaning m4-native and quilt-native? Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] RDEPENDS of packages created by PACKAGES_DYNAMIC not built before image rootfs
Hi, pulseaudio has RDEPENDS_pulseaudio-module-console-kit =+ "consolekit" and pulseaudio-module-console-kit is dynamic package PACKAGES_DYNAMIC += "^pulseaudio-lib.* ^pulseaudio-module.* ^libpulse-lib.* ^libpulse-module.* " If you have image where consolekit is pulled to image only by pulseaudio-module-console-kit (e.g. through pulseaudio-server). Then consolekit is not built before image do_rootfs is executed and do_rootfs fails. Easy way to reproduce this is to build e.g. core-image-minimal with pulseaudio-module-console-kit or pulseaudio-server added to IMAGE_INSTALL. Will fail with: * satisfy_dependencies_for: Cannot satisfy the following dependencies for pulseaudio-server: *consolekit * * opkg_install_cmd: Cannot install package pulseaudio-server. Not sure what's proper fix, bitbake probably just checks that right provider for pulseaudio-module-console-kit is pulseaudio because of PACKAGES_DYNAMIC, but does not check RDEPENDS_pulseaudio-module-console-kit after that. We can add consolekit to build time deps like it was before, but that's just work around and not correct fix. Also filled as https://bugzilla.yoctoproject.org/show_bug.cgi?id=3498 Cheers, -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] autogen: use pkg-config directly instead of guile-config
The autoconf macros in autogen use dpkg (!) and guile-config to determine what/where Guile is. If the build host has an installed guile, these can produce conflicting results. More interestingly, if the Guile library source and compiled form have bad timestamps (source newer than compiled) the configure scripts knows that Guile is present but doesn't know what version it is, resulting in compile errors. [ YOCTO #3370 (partially) ] Signed-off-by: Ross Burton --- .../autogen/autogen-native_5.12.bb |5 +- meta/recipes-devtools/autogen/files/guile.patch| 177 2 files changed, 180 insertions(+), 2 deletions(-) create mode 100644 meta/recipes-devtools/autogen/files/guile.patch diff --git a/meta/recipes-devtools/autogen/autogen-native_5.12.bb b/meta/recipes-devtools/autogen/autogen-native_5.12.bb index eb3721d..d13af08 100644 --- a/meta/recipes-devtools/autogen/autogen-native_5.12.bb +++ b/meta/recipes-devtools/autogen/autogen-native_5.12.bb @@ -8,12 +8,13 @@ SECTION = "devel" LICENSE = "GPLv3" LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504" -SRC_URI = "${GNU_MIRROR}/autogen/rel${PV}/autogen-${PV}.tar.gz" +SRC_URI = "${GNU_MIRROR}/autogen/rel${PV}/autogen-${PV}.tar.gz \ + file://guile.patch" SRC_URI[md5sum] = "6c6671b76021fb30dd43b0d5fdb7180b" SRC_URI[sha256sum] = "37e885d6c8a58f33ab198d38bb972fa4c14236f951d628161dde6e20527d0df2" -PR = "r2" +PR = "r3" DEPENDS = "guile-native libtool-native libxml2-native" RDEPENDS = "automake pkgconfig" diff --git a/meta/recipes-devtools/autogen/files/guile.patch b/meta/recipes-devtools/autogen/files/guile.patch new file mode 100644 index 000..f485bba --- /dev/null +++ b/meta/recipes-devtools/autogen/files/guile.patch @@ -0,0 +1,177 @@ +Disable the autoconf macros that use dpkg (!) and guile-config to determine what +version and where guile is installed, and just use pkg-config directly (guile-config is a deprecated wrapper around pkg-config). + +Signed-off-by: Ross Burton +Upstream-Status: Pending (should be submitted) + +Index: a/config/ag_macros.m4 +=== +--- a/config/ag_macros.m4 2012-11-27 14:53:24.336205621 + b/config/ag_macros.m4 2012-11-27 16:16:42.968271120 + +@@ -163,146 +162,20 @@ + + + AC_DEFUN([AG_WITHLIB_GUILE],[ +- AC_ARG_WITH([libguile], +-AS_HELP_STRING([--with-libguile], [libguile installation prefix]), +-[ag_cv_with_libguile_root=${with_libguile}], +-AC_CACHE_CHECK([whether with-libguile was specified], ag_cv_with_libguile_root, +- ag_cv_with_libguile_root=no) +- ) # end of AC_ARG_WITH libguile +- +- if test "${with_libguile+set}" = set && \ +- test "${withval}" = no +- then ## disabled by request +-ag_cv_with_libguile_root=no +-ag_cv_with_libguile_cflags=no +-ag_cv_with_libguile_libs=no +- else +- +- AC_ARG_WITH([libguile-cflags], +-AS_HELP_STRING([--with-libguile-cflags], [libguile compile flags]), +-[ag_cv_with_libguile_cflags=${with_guile_cflags}], +-AC_CACHE_CHECK([whether with-libguile-cflags was specified], ag_cv_with_libguile_cflags, +- ag_cv_with_libguile_cflags=no) +- ) # end of AC_ARG_WITH libguile-cflags +- +- AC_ARG_WITH([libguile-libs], +-AS_HELP_STRING([--with-libguile-libs], [libguile link command arguments]), +-[ag_cv_with_libguile_libs=${with_guile_libs}], +-AC_CACHE_CHECK([whether with-libguile-libs was specified], ag_cv_with_libguile_libs, +- ag_cv_with_libguile_libs=no) +- ) # end of AC_ARG_WITH libguile-libs +- +- case "X${ag_cv_with_libguile_cflags}" in +- Xyes|Xno|X ) +-case "X${ag_cv_with_libguile_root}" in +-Xyes|Xno|X ) ag_cv_with_libguile_cflags=no ;; +-* ) ag_cv_with_libguile_cflags=-I${ag_cv_with_libguile_root}/include ;; +-esac +- esac +- case "X${ag_cv_with_libguile_libs}" in +- Xyes|Xno|X ) +-case "X${ag_cv_with_libguile_root}" in +-Xyes|Xno|X ) ag_cv_with_libguile_libs=no ;; +-* )ag_cv_with_libguile_libs="-L${ag_cv_with_libguile_root}/lib -lguile";; +-esac +- esac +- ag_save_CPPFLAGS="${CPPFLAGS}" +- ag_save_LIBS="${LIBS}" +- case "X${ag_cv_with_libguile_cflags}" in +- Xyes|Xno|X ) +-f=`guile-config compile 2>/dev/null` || f='' +-test -n "${f}" && ag_cv_with_libguile_cflags="${f}" && \ +- AC_MSG_NOTICE([guile-config used for CFLAGS: $f]) ;; +- esac +- case "X${ag_cv_with_libguile_libs}" in +- Xyes|Xno|X ) +-f=`guile-config link 2>/dev/null` || f='' +-test -n "${f}" && ag_cv_with_libguile_libs="${f}" && \ +- AC_MSG_NOTICE([guile-config used for LIBS: $f]) ;; +- esac +- fi ## disabled by request +- +- case "X${ag_cv_with_libguile_cflags}" in +- Xyes|Xno|X ) +-ag_cv_with_libguile_cflags="" ;; +- * ) CPPFLAGS="${CPPFLAGS} ${ag_cv_with_libguile_cflags}" ;; +- esac +- case "X${ag_cv_with_libguile_libs}" in +- Xyes|Xno|X ) +-LIBS="${LIBS} -lguile" +-ag_
[OE-core] Perl 'native' path
hi, i am getting the following build error: ERROR: Function failed: do_rootfs (see /data/ubuntu-omap/jenkins/jobs/yocto-meta-ti-danny/workspace/mybuild/tmp/work/pandaboard-poky-linux-gnueabi/core-image-x11-1.0-r0/temp/log.do_rootfs.28213 for further information) ERROR: Logfile of failure stored in: /data/ubuntu-omap/jenkins/jobs/yocto-meta-ti-danny/workspace/mybuild/tmp/work/pandaboard-poky-linux-gnueabi/core-image-x11-1.0-r0/temp/log.do_rootfs.28213 Log data follows: | DEBUG: Executing shell function do_rootfs | Can't locate Dpkg.pm in @INC (@INC contains: /apps/perl/5.8.3/lib/5.8.3/x86_64-linux-thread-multi /apps/perl/5.8.3/lib/5.8.3 /apps/perl/5.8.3/lib/site_perl/5.8.3/x86_64-linux-thread-multi /apps/perl/5.8.3/lib/site_perl/5.8.3 /apps/perl/5.8.3/lib/site_perl .) at /data/ubuntu-omap/jenkins/jobs/yocto-meta-ti-danny/workspace/mybuild/tmp/sysroots/x86_64-linux/usr/bin/dpkg-scanpackages line 27. i am trying to setup some daily builds on some corporate administrated machines... and what happens is that dpkg-scanpackage perl script has this: $ more sysroots/x86_64-linux/usr/bin/dpkg-scanpackages #!/usr/local/bin/perl So in turns my build will attempt to use whatever I have in /usr/local/bin (AFAIU), which is problematic in my case as this points to a corporate version (/apps/perl), which then leads to build failure. I would expect all scripts to use the perl-native binary, instead, and search for Perl modules in the sysroot folder. does that make any sense? is there something wrong with what I am doing (beyond using a corporate server which I can't administrate ;-) thx ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] RDEPENDS of packages created by PACKAGES_DYNAMIC not built before image rootfs
On Tue, Nov 27, 2012 at 1:41 PM, Martin Jansa wrote: > pulseaudio has > RDEPENDS_pulseaudio-module-console-kit =+ "consolekit" > > and pulseaudio-module-console-kit is dynamic package > PACKAGES_DYNAMIC += "^pulseaudio-lib.* ^pulseaudio-module.* ^libpulse-lib.* > ^libpulse-module.* " > > If you have image where consolekit is pulled to image only by > pulseaudio-module-console-kit (e.g. through pulseaudio-server). > Then consolekit is not built before image do_rootfs is executed and do_rootfs > fails. > > Easy way to reproduce this is to build e.g. core-image-minimal with > pulseaudio-module-console-kit or pulseaudio-server added to IMAGE_INSTALL. > Will fail with: > * satisfy_dependencies_for: Cannot satisfy the following dependencies for > pulseaudio-server: > *consolekit * > * opkg_install_cmd: Cannot install package pulseaudio-server. > > > Not sure what's proper fix, bitbake probably just checks that right provider > for > pulseaudio-module-console-kit is pulseaudio because of PACKAGES_DYNAMIC, but > does not check > RDEPENDS_pulseaudio-module-console-kit after that. > > We can add consolekit to build time deps like it was before, but that's just > work around and not correct fix. > > Also filled as > https://bugzilla.yoctoproject.org/show_bug.cgi?id=3498 Yes; I have this issue in an internal recipe as well. I workarounded it adding them in the depends. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] Minutes: OE TSC 23 Oct 2012
OpenEmbedded Technical Steering Committee 23 October 2012 Attendees: Koen, Paul, Khem, Richard Apologies: Mark Notes: Jefro Agenda & Results 1. pick a chair bluelightning ___ 2. new issues a. Meetup at ELCE -> OE general assembly Weds eve 5pm, Yocto Project Developer day Thurs b. RFC for the secondary toolchain (fray) how to document as best practice? possibly sample secondary toolchain layer as template no changes to oe-core, possibly add an include file -> in progress c. RPM and package feeds packages_rpm, rootfs_rpm doesn't use Zypper fray proposes replacing with SMART after 1.3 release smaller footprint, python based -> fray will write proposal after 1.3 -> in progress d. patchwork queue bluelightning did a massive clearout of patchwork, got rid of 3 pages a number of oe-classic patches left koen notes that git hooks catch only 80% of patches, and then only for master known to fail with accented names => koen to go through what is left in patchwork for meta-oe => bluelightning to send note to ml re oe-classic patches ___ 3. lingering issues a. raise awareness of "janitor" list, QA "bugs" b. pre/post install scripting (fray) holding for 1.4 c. document whitespace changes to the shell RP edited OE style guide with new info, linked to YP => fray to update patch guidelines d. documentation need someone to work on OE wiki pages RP, bluelightning, fray to hopefully work on it together -> attempt to find time at ELCE ___ 4. status a. oe-core release at -rc3 now, -rc4 tomorrow, hi-priority issues identified release branches exist issues with 3.4.10 on ARM, bumped to 3.4.11 (uniprocessor) new bugzilla category for image deployment issues -> good to go with the branch as it stands now -> 1.4 is open for development now -> merging systemd into master is on 1.4 feature list b. infrastructure disks failed last week Tom & Martin working on setting up jenkins c. 1.4 planning PR issues pre/post install scripting SMART systemd into master Raw Transcript: (9:05:32 AM) RP: Who do we have? (9:05:54 AM) Jefro: I am in another phone meeting concurrently but will stay on here for notes. Agenda at http://pastebin.com/rF7Hppaf (note: I switched New & Lingering issues) (9:07:06 AM) koen: present (9:07:48 AM) RP: I'm also double booked. This week is crzay crazy crazy for meetings :( (9:07:53 AM) RP: Do we have much to talk about (9:07:58 AM) RP: fray: ping? (9:08:01 AM) RP: bluelightning: ping? (9:08:22 AM) bluelightning: I wanted to raise OE patchwork (9:08:29 AM) bluelightning: specifically the queue (9:08:34 AM) koen: judging from the agenda, no new items (9:09:03 AM) RP: 1.4 update: I think we're good to go with the branch as it stands now (9:09:08 AM) RP: er, 1.3 update (9:10:53 AM) RP: and 1.4 is open for development now and work has started (9:11:47 AM) koen: hmm, that means I need to send a "volunteers wanted" mail for meta-oe 1.3 branch (9:12:44 AM) koen: shall we skip to patchworK? (9:12:58 AM) bluelightning: I'll assume so (9:13:09 AM) bluelightning: I had a massive clearout of patchwork the other day (9:13:19 AM) koen: yay! (9:13:34 AM) bluelightning: got rid of about 3 pages of merged/superseded/invalid stuff (9:14:05 AM) bluelightning: so what we're left with is a number of patches for OE-Classic which I'm not sure what we want to do with (9:14:08 AM) koen: the git hooks only catch about 80% of the patches and only for master (9:14:27 AM) bluelightning: and some unmerged patches for meta-oe some of which go back a few months (9:15:36 AM) bluelightning: koen: indeed... do you know how it does the comparison? (9:15:41 AM) RP: are we talking about oe-core or oe-classic here? (9:16:03 AM) koen: bluelightning: no, but iirc it's the script that comes with patchwork (9:16:13 AM) bluelightning: RP: we're talking about the OE patchwork which includes patches for OE-Classic, meta-oe and other layers on top of OE-Core that aren't OE-Core (9:16:16 AM) koen: bluelightning: it is know to fail with accented names (9:16:33 AM) koen: known* (9:16:55 AM) RP: bluelightning: So what is the question? (9:17:01 AM) bluelightning: koen: ok, I was wondering if for example it handled additional signed-off-by being added (9:17:33 AM) bluelightning: RP: there are two questions: 1) can we deal with the queue of meta-oe patches especially the old ones (9:17:56 AM) bluelightning: and 2) what do we do with the OE-Classic patches? is it worth keeping them around? (9:18:05 AM) bluelightning: some of them were never replied to (9:18:10 AM) RP: Is anyone using oe-classic now? (9:18:19 AM) bluelightning: RP: I suspect they still are yes (9:18:30 AM) blueligh
[OE-core] locale data broken in gstreamer
In last rebuild from scratch I've noticed couple of weird locale data: Collected errors: * check_data_file_clashes: Package gst-plugins-base-locale-en-gb wants * to install file /usr/share/locale/en_GB/LC_MESSAGES/.mo But that file is already provided by package * gstreamer-locale-en-gb * check_data_file_clashes: Package gst-plugins-base-locale-cs wants to * install file /usr/share/locale/cs/LC_MESSAGES/.mo But that file is already provided by package * gstreamer-locale-cs All gstreamer and gst-plugins-base locales package just .mo file. from log.do_install: make[1]: Entering directory `/OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/gstreamer/0.10.36-r1/gstreamer-0.10.36/po' installing af.gmo as /OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/gstreamer/0.10.36-r1/image/usr/share/locale/af/LC_MESSAGES/.mo installing az.gmo as /OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/gstreamer/0.10.36-r1/image/usr/share/locale/az/LC_MESSAGES/.mo installing be.gmo as /OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/gstreamer/0.10.36-r1/image/usr/share/locale/be/LC_MESSAGES/.mo They are installed to $(DOMAIN).mo gstreamer-0.10.36/po/Makefile.in.in:$(INSTALL_DATA) $$realcat $(DESTDIR)$$dir/$(DOMAIN).mo; \ gstreamer-0.10.36/po/Makefile.in.in:echo "installing $$realcat as $(DESTDIR)$$dir/$(DOMAIN).mo"; \ and DOMAIN should be set to GETTEXT_PACKAGE (gstreamer-0.10) ./gstreamer-0.10.36/po/Makevars:DOMAIN = $(GETTEXT_PACKAGE) ./gstreamer-0.10.36/po/Makefile:DOMAIN = $(GETTEXT_PACKAGE) Anyone else seen this, any idea why it fails now? gst* recipes weren't changed lately IIRC, so maybe some change in gettext which can break more recipes? Cheers, signature.asc Description: Digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] locale data broken in gstreamer
On Tue, Nov 27, 2012 at 07:23:06PM +0100, Martin Jansa wrote: > In last rebuild from scratch I've noticed couple of weird locale data: > > Collected errors: > * check_data_file_clashes: Package gst-plugins-base-locale-en-gb wants > * to install file /usr/share/locale/en_GB/LC_MESSAGES/.mo > But that file is already provided by package * gstreamer-locale-en-gb > * check_data_file_clashes: Package gst-plugins-base-locale-cs wants to > * install file /usr/share/locale/cs/LC_MESSAGES/.mo > But that file is already provided by package * gstreamer-locale-cs > > All gstreamer and gst-plugins-base locales package just .mo file. > > from log.do_install: > make[1]: Entering directory > `/OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/gstreamer/0.10.36-r1/gstreamer-0.10.36/po' > installing af.gmo as > /OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/gstreamer/0.10.36-r1/image/usr/share/locale/af/LC_MESSAGES/.mo > installing az.gmo as > /OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/gstreamer/0.10.36-r1/image/usr/share/locale/az/LC_MESSAGES/.mo > installing be.gmo as > /OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/gstreamer/0.10.36-r1/image/usr/share/locale/be/LC_MESSAGES/.mo > > They are installed to $(DOMAIN).mo > gstreamer-0.10.36/po/Makefile.in.in:$(INSTALL_DATA) $$realcat > $(DESTDIR)$$dir/$(DOMAIN).mo; \ > gstreamer-0.10.36/po/Makefile.in.in:echo "installing $$realcat as > $(DESTDIR)$$dir/$(DOMAIN).mo"; \ > > and DOMAIN should be set to GETTEXT_PACKAGE (gstreamer-0.10) > ./gstreamer-0.10.36/po/Makevars:DOMAIN = $(GETTEXT_PACKAGE) > ./gstreamer-0.10.36/po/Makefile:DOMAIN = $(GETTEXT_PACKAGE) > > Anyone else seen this, any idea why it fails now? gst* recipes weren't > changed lately IIRC, > so maybe some change in gettext which can break more recipes? buildhistory shows that it got broken around Oct 21 Maybe someone with OEBasicHash can pinpoint it better? $ git show -1 47613e04c950dee281bf4531ef3fb3b71a90c906 | grep gst-plugins-base-locale-en-gb -A 11 diff --git a/packages/armv4t-oe-linux-gnueabi/gst-plugins-base/gst-plugins-base-locale-en-gb/latest b/packages/armv4t-oe-linux-gnueabi/gst-plugins-base/gst-plugins-base-locale-en-gb/latest index 74a76ae..ebcab7f 100644 --- a/packages/armv4t-oe-linux-gnueabi/gst-plugins-base/gst-plugins-base-locale-en-gb/latest +++ b/packages/armv4t-oe-linux-gnueabi/gst-plugins-base/gst-plugins-base-locale-en-gb/latest @@ -1,7 +1,7 @@ PV = 0.10.36 PR = r5 -RDEPENDS = gst-plugins-base virtual-locale-en-gb -RRECOMMENDS = +RDEPENDS = +RRECOMMENDS = gst-plugins-base virtual-locale-en-gb PKGSIZE = 1165 FILES = /usr/share/locale/en_GB -FILELIST = /usr/share/locale/en_GB/LC_MESSAGES/gst-plugins-base-0.10.mo +FILELIST = /usr/share/locale/en_GB/LC_MESSAGES/.mo $ git show -1 47613e04c950dee281bf4531ef3fb3b71a90c906 | grep gstreamer-locale-en-gb -A 11 diff --git a/packages/armv4t-oe-linux-gnueabi/gstreamer/gstreamer-locale-en-gb/latest b/packages/armv4t-oe-linux-gnueabi/gstreamer/gstreamer-locale-en-gb/latest index fffca5a..3affa1a 100644 --- a/packages/armv4t-oe-linux-gnueabi/gstreamer/gstreamer-locale-en-gb/latest +++ b/packages/armv4t-oe-linux-gnueabi/gstreamer/gstreamer-locale-en-gb/latest @@ -1,7 +1,7 @@ PV = 0.10.36 PR = r1 -RDEPENDS = gstreamer virtual-locale-en-gb -RRECOMMENDS = +RDEPENDS = +RRECOMMENDS = gstreamer virtual-locale-en-gb PKGSIZE = 12518 FILES = /usr/share/locale/en_GB -FILELIST = /usr/share/locale/en_GB/LC_MESSAGES/gstreamer-0.10.mo +FILELIST = /usr/share/locale/en_GB/LC_MESSAGES/.mo Cheers, -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] locale data broken in gstreamer
On 11/27/12 12:23 PM, Martin Jansa wrote: In last rebuild from scratch I've noticed couple of weird locale data: Paul E and I just observed this as well... My build machine is an -old- FC13 machine.. system we found it on was x86. --Mark Collected errors: * check_data_file_clashes: Package gst-plugins-base-locale-en-gb wants * to install file /usr/share/locale/en_GB/LC_MESSAGES/.mo But that file is already provided by package * gstreamer-locale-en-gb * check_data_file_clashes: Package gst-plugins-base-locale-cs wants to * install file /usr/share/locale/cs/LC_MESSAGES/.mo But that file is already provided by package * gstreamer-locale-cs All gstreamer and gst-plugins-base locales package just .mo file. from log.do_install: make[1]: Entering directory `/OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/gstreamer/0.10.36-r1/gstreamer-0.10.36/po' installing af.gmo as /OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/gstreamer/0.10.36-r1/image/usr/share/locale/af/LC_MESSAGES/.mo installing az.gmo as /OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/gstreamer/0.10.36-r1/image/usr/share/locale/az/LC_MESSAGES/.mo installing be.gmo as /OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/gstreamer/0.10.36-r1/image/usr/share/locale/be/LC_MESSAGES/.mo They are installed to $(DOMAIN).mo gstreamer-0.10.36/po/Makefile.in.in:$(INSTALL_DATA) $$realcat $(DESTDIR)$$dir/$(DOMAIN).mo; \ gstreamer-0.10.36/po/Makefile.in.in:echo "installing $$realcat as $(DESTDIR)$$dir/$(DOMAIN).mo"; \ and DOMAIN should be set to GETTEXT_PACKAGE (gstreamer-0.10) ./gstreamer-0.10.36/po/Makevars:DOMAIN = $(GETTEXT_PACKAGE) ./gstreamer-0.10.36/po/Makefile:DOMAIN = $(GETTEXT_PACKAGE) Anyone else seen this, any idea why it fails now? gst* recipes weren't changed lately IIRC, so maybe some change in gettext which can break more recipes? Cheers, ___ 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] locale data broken in gstreamer
On Tue, Nov 27, 2012 at 12:44:21PM -0600, Mark Hatle wrote: > On 11/27/12 12:23 PM, Martin Jansa wrote: > > In last rebuild from scratch I've noticed couple of weird locale data: > > Paul E and I just observed this as well... My build machine is an -old- FC13 > machine.. system we found it on was x86. Mine is bleading edge gentoo x86_64 and system gettext wasn't changed too (using sys-devel/gettext-0.18.1.1-r2 since Apr 2011) Cheers, > > --Mark > > > Collected errors: > > * check_data_file_clashes: Package gst-plugins-base-locale-en-gb wants > > * to install file /usr/share/locale/en_GB/LC_MESSAGES/.mo > > But that file is already provided by package * > > gstreamer-locale-en-gb > > * check_data_file_clashes: Package gst-plugins-base-locale-cs wants to > > * install file /usr/share/locale/cs/LC_MESSAGES/.mo > > But that file is already provided by package * gstreamer-locale-cs > > > > All gstreamer and gst-plugins-base locales package just .mo file. > > > > from log.do_install: > > make[1]: Entering directory > > `/OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/gstreamer/0.10.36-r1/gstreamer-0.10.36/po' > > installing af.gmo as > > /OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/gstreamer/0.10.36-r1/image/usr/share/locale/af/LC_MESSAGES/.mo > > installing az.gmo as > > /OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/gstreamer/0.10.36-r1/image/usr/share/locale/az/LC_MESSAGES/.mo > > installing be.gmo as > > /OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/gstreamer/0.10.36-r1/image/usr/share/locale/be/LC_MESSAGES/.mo > > > > They are installed to $(DOMAIN).mo > > gstreamer-0.10.36/po/Makefile.in.in:$(INSTALL_DATA) $$realcat > > $(DESTDIR)$$dir/$(DOMAIN).mo; \ > > gstreamer-0.10.36/po/Makefile.in.in:echo "installing $$realcat as > > $(DESTDIR)$$dir/$(DOMAIN).mo"; \ > > > > and DOMAIN should be set to GETTEXT_PACKAGE (gstreamer-0.10) > > ./gstreamer-0.10.36/po/Makevars:DOMAIN = $(GETTEXT_PACKAGE) > > ./gstreamer-0.10.36/po/Makefile:DOMAIN = $(GETTEXT_PACKAGE) > > > > Anyone else seen this, any idea why it fails now? gst* recipes weren't > > changed lately IIRC, > > so maybe some change in gettext which can break more recipes? > > > > Cheers, > > > > > > > > ___ > > Openembedded-core mailing list > > Openembedded-core@lists.openembedded.org > > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core > > > > > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] RDEPENDS of packages created by PACKAGES_DYNAMIC not built before image rootfs
On Tue, 2012-11-27 at 16:41 +0100, Martin Jansa wrote: > Hi, > > pulseaudio has > RDEPENDS_pulseaudio-module-console-kit =+ "consolekit" > > and pulseaudio-module-console-kit is dynamic package > PACKAGES_DYNAMIC += "^pulseaudio-lib.* ^pulseaudio-module.* ^libpulse-lib.* > ^libpulse-module.* " > > If you have image where consolekit is pulled to image only by > pulseaudio-module-console-kit (e.g. through pulseaudio-server). > Then consolekit is not built before image do_rootfs is executed and do_rootfs > fails. > > Easy way to reproduce this is to build e.g. core-image-minimal with > pulseaudio-module-console-kit or pulseaudio-server added to IMAGE_INSTALL. > Will fail with: > * satisfy_dependencies_for: Cannot satisfy the following dependencies for > pulseaudio-server: > *consolekit * > * opkg_install_cmd: Cannot install package pulseaudio-server. > > > Not sure what's proper fix, bitbake probably just checks that right provider > for > pulseaudio-module-console-kit is pulseaudio because of PACKAGES_DYNAMIC, but > does not check > RDEPENDS_pulseaudio-module-console-kit after that. > > We can add consolekit to build time deps like it was before, but that's just > work around and not correct fix. > > Also filled as > https://bugzilla.yoctoproject.org/show_bug.cgi?id=3498 Well, you can't have this both ways :) Bitbake doesn't know which modules this package will produce since its using PACKAGES_DYNAMIC. It does its best effort to try and find DEPENDS but it can't take the regexps and come up with "pulseaudio-module-console-kit", hence it doesn't see the RDEPENDS. There isn't any generic way we can teach it to do that either. If it did, it would simply always build consolekit which you say you don't want so its not relevant anyway. So basically, you need to decide whether you want consolekit enabled or not and build accordingly, there is nothing you can do within bitbake to "mind read" what the image is going to want... Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gcc-cross: Explicitly depend on linux-libc-headers
On Thu, Nov 22, 2012 at 3:36 PM, Richard Purdie wrote: > gcc-cross cannot build without linux-libc-headers but doesn't explicitly > depend on > it relying on the implied dependency through libc. With cases where pieces > can be installed through sstate, we now need this explicit dependency to > ensure builds with partial sstate work. > > Signed-off-by: Richard Purdie > --- > diff --git a/meta/recipes-devtools/gcc/gcc-cross.inc > b/meta/recipes-devtools/gcc/gcc-cross.inc > index 6d160d6..cde08ee 100644 > --- a/meta/recipes-devtools/gcc/gcc-cross.inc > +++ b/meta/recipes-devtools/gcc/gcc-cross.inc > @@ -1,6 +1,6 @@ > inherit cross > > -DEPENDS = "virtual/${TARGET_PREFIX}binutils > virtual/${TARGET_PREFIX}libc-for-gcc ${NATIVEDEPS}" > +DEPENDS = "virtual/${TARGET_PREFIX}binutils > virtual/${TARGET_PREFIX}libc-for-gcc linux-libc-headers ${NATIVEDEPS}" How would you suggest not forcing a rebuild of all components if the linux headers signature changes? During our normal development we change Linux headers for things that would in no way effect gcc or even libc. It's painful to watch a complete rebuild occur because of this. Just have a different recipe for headers for some components? -M ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] RDEPENDS of packages created by PACKAGES_DYNAMIC not built before image rootfs
On Tue, Nov 27, 2012 at 08:11:42PM +, Richard Purdie wrote: > On Tue, 2012-11-27 at 16:41 +0100, Martin Jansa wrote: > > Hi, > > > > pulseaudio has > > RDEPENDS_pulseaudio-module-console-kit =+ "consolekit" > > > > and pulseaudio-module-console-kit is dynamic package > > PACKAGES_DYNAMIC += "^pulseaudio-lib.* ^pulseaudio-module.* ^libpulse-lib.* > > ^libpulse-module.* " > > > > If you have image where consolekit is pulled to image only by > > pulseaudio-module-console-kit (e.g. through pulseaudio-server). > > Then consolekit is not built before image do_rootfs is executed and > > do_rootfs fails. > > > > Easy way to reproduce this is to build e.g. core-image-minimal with > > pulseaudio-module-console-kit or pulseaudio-server added to IMAGE_INSTALL. > > Will fail with: > > * satisfy_dependencies_for: Cannot satisfy the following dependencies for > > pulseaudio-server: > > *consolekit * > > * opkg_install_cmd: Cannot install package pulseaudio-server. > > > > > > Not sure what's proper fix, bitbake probably just checks that right > > provider for > > pulseaudio-module-console-kit is pulseaudio because of PACKAGES_DYNAMIC, > > but does not check > > RDEPENDS_pulseaudio-module-console-kit after that. > > > > We can add consolekit to build time deps like it was before, but that's > > just > > work around and not correct fix. > > > > Also filled as > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=3498 > > Well, you can't have this both ways :) IMHO Only one way is correct and that would be enough :). > Bitbake doesn't know which modules this package will produce since its > using PACKAGES_DYNAMIC. It does its best effort to try and find DEPENDS > but it can't take the regexps and come up with > "pulseaudio-module-console-kit", hence it doesn't see the RDEPENDS. > There isn't any generic way we can teach it to do that either. If it > did, it would simply always build consolekit which you say you don't > want so its not relevant anyway. > > So basically, you need to decide whether you want consolekit enabled or > not and build accordingly, there is nothing you can do within bitbake to > "mind read" what the image is going to want... No, you know that you will need pulseaudio-module-console-kit because pulseaudio-server RDEPENDs on it (not on any pulseaudio-module-* but pulseaudio-module-console-kit exactly). So it's not really mind reading. If it's not possible with current code-base then we should document it and add some work around in pulseaudio (I'm fine with building consolekit even when it's not used later). Cheers, -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] RDEPENDS of packages created by PACKAGES_DYNAMIC not built before image rootfs
On 11/27/12 2:23 PM, Martin Jansa wrote: On Tue, Nov 27, 2012 at 08:11:42PM +, Richard Purdie wrote: On Tue, 2012-11-27 at 16:41 +0100, Martin Jansa wrote: Hi, pulseaudio has RDEPENDS_pulseaudio-module-console-kit =+ "consolekit" and pulseaudio-module-console-kit is dynamic package PACKAGES_DYNAMIC += "^pulseaudio-lib.* ^pulseaudio-module.* ^libpulse-lib.* ^libpulse-module.* " If you have image where consolekit is pulled to image only by pulseaudio-module-console-kit (e.g. through pulseaudio-server). Then consolekit is not built before image do_rootfs is executed and do_rootfs fails. Easy way to reproduce this is to build e.g. core-image-minimal with pulseaudio-module-console-kit or pulseaudio-server added to IMAGE_INSTALL. Will fail with: * satisfy_dependencies_for: Cannot satisfy the following dependencies for pulseaudio-server: *consolekit * * opkg_install_cmd: Cannot install package pulseaudio-server. Not sure what's proper fix, bitbake probably just checks that right provider for pulseaudio-module-console-kit is pulseaudio because of PACKAGES_DYNAMIC, but does not check RDEPENDS_pulseaudio-module-console-kit after that. We can add consolekit to build time deps like it was before, but that's just work around and not correct fix. Also filled as https://bugzilla.yoctoproject.org/show_bug.cgi?id=3498 Well, you can't have this both ways :) IMHO Only one way is correct and that would be enough :). Bitbake doesn't know which modules this package will produce since its using PACKAGES_DYNAMIC. It does its best effort to try and find DEPENDS but it can't take the regexps and come up with "pulseaudio-module-console-kit", hence it doesn't see the RDEPENDS. There isn't any generic way we can teach it to do that either. If it did, it would simply always build consolekit which you say you don't want so its not relevant anyway. So basically, you need to decide whether you want consolekit enabled or not and build accordingly, there is nothing you can do within bitbake to "mind read" what the image is going to want... For the resolver, it has to use the RPROVIDES, PACKAGES and PACKAGES_DYNAMIC... No, you know that you will need pulseaudio-module-console-kit because pulseaudio-server RDEPENDs on it (not on any pulseaudio-module-* but pulseaudio-module-console-kit exactly). So it's not really mind reading. But after the recipe has been built, the required item from PACKAGES_DYNAMIC should now be in PACKAGES... and if it doesn't end up in the PACKAGES list, it would be a good idea to at a minimum trigger a warning... The catch is, is there any way to tell if something from PACKAGES_DYNAMIC was used.. --Mark If it's not possible with current code-base then we should document it and add some work around in pulseaudio (I'm fine with building consolekit even when it's not used later). Cheers, ___ 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] [PATCH 1/2] pulseaudio: fix compilation on RHEL-5.8 64bit machine
On 11/26/2012 09:34 PM, jhuang0 wrote: On 11/22/2012 4:55 PM, Burton, Ross wrote: Hi, This patch is too hacky to go in at the moment. Hi Ross, Thanks for your comments, in fact the patch was for a weird edge case in the old version, I looked for the history and it seemed to be added as a workaround. And I tried some days but couldn't reproduce the issue in current pulseaudio 2.1, so I shouldn't have send this, sorry about that. Aws, please correct me if I'm wrong, thanks! Agreed. This was a quick fix for a very specific case. If you can confirm that it is not there anymore, which, by the looks of it, seems that you have done; then let's get rid of it. Thanks Jackie. Aws\ Thanks, Jackie On 22 November 2012 06:46, wrote: ../bitbake_build/tmp/sysroots/qemux86-64/usr/lib64/libgdk-x11-2.0.so: undefined reference to `XRRGetOutputInfo' Which means your GTK+ linkage is broken, because libgdk should be linking to libXrandr. Mine is, can you verify that yours is too? +-AM_LDADD = $(PTHREAD_LIBS) $(INTLLIBS) ++AM_LDADD = $(PTHREAD_LIBS) $(INTLLIBS) -lXrandr You're adding linkage to libXrandr to every part of PulseAudio. What binary in pulseaudio is failing to compile with this error? -DEPENDS += "libjson gdbm speex libxml-parser-perl-native" +DEPENDS += "libjson gdbm speex libxml-parser-perl-native \ + ${@base_contains('DISTRO_FEATURES', 'x11', 'libxrandr', '', d)}" pulseaudio.inc has: DEPENDS = "libatomics-ops liboil avahi libsamplerate0 libsndfile1 libtool \ ${@base_contains('DISTRO_FEATURES', 'x11', 'virtual/libx11 libxtst libice libsm libxcb gtk+', '', d)}" As gtk+ pulls in libxrandr, this is redundant. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gst-meta-base: Make ximagesing optional on x11 DISTRO_FEATURE
Ross, This one should hit Danny next also if possible. Thanks Sau! On 11/25/2012 10:15 PM, Saul Wold wrote: If x11 is disabled from DISTRO_FEATURE we don't build the ximagesink package, but it still becomes a dependency in the final image which causes a failure Signed-off-by: Saul Wold --- .../gstreamer/gst-meta-base_0.10.bb|3 +++ 1 file changed, 3 insertions(+) diff --git a/meta/recipes-multimedia/gstreamer/gst-meta-base_0.10.bb b/meta/recipes-multimedia/gstreamer/gst-meta-base_0.10.bb index 2fb39d5..0889437 100644 --- a/meta/recipes-multimedia/gstreamer/gst-meta-base_0.10.bb +++ b/meta/recipes-multimedia/gstreamer/gst-meta-base_0.10.bb @@ -16,7 +16,10 @@ PACKAGES = "\ ALLOW_EMPTY = "1" +X11_RDEPENDS = "${@base_contains('DISTRO_FEATURES', 'x11', 'gst-plugin-base-ximagesink', '', d)}" + RDEPENDS_gst-meta-base = "\ +${X11_RDEPENDS} \ gstreamer \ gst-plugins-base-playbin \ gst-plugins-base-decodebin \ ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libpng: update to upstream version 1.2.50
On 11/27/2012 01:06 AM, Marko Lindqvist wrote: On 27 November 2012 10:54, Richard Purdie wrote: On Tue, 2012-11-27 at 05:18 +0200, Marko Lindqvist wrote: Signed-off-by: Marko Lindqvist What changed in the LICENSE? Version number and release date. Please resend the pull request with this in the commit header Thanks Sau! Cheers, Richard --- .../libpng/{libpng_1.2.49.bb => libpng_1.2.50.bb} | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) rename meta/recipes-multimedia/libpng/{libpng_1.2.49.bb => libpng_1.2.50.bb} (52%) diff --git a/meta/recipes-multimedia/libpng/libpng_1.2.49.bb b/meta/recipes-multimedia/libpng/libpng_1.2.50.bb similarity index 52% rename from meta/recipes-multimedia/libpng/libpng_1.2.49.bb rename to meta/recipes-multimedia/libpng/libpng_1.2.50.bb index d33a9f5..211e357 100644 --- a/meta/recipes-multimedia/libpng/libpng_1.2.49.bb +++ b/meta/recipes-multimedia/libpng/libpng_1.2.50.bb @@ -3,15 +3,15 @@ DESCRIPTION = "PNG Library" HOMEPAGE = "http://www.libpng.org/"; SECTION = "libs" LICENSE = "Libpng" -LIC_FILES_CHKSUM = "file://LICENSE;md5=20110633230abd47fe8680afa75f1492 \ - file://png.h;startline=308;endline=422;md5=edd1c552386a8c3773d90e278ae30891" +LIC_FILES_CHKSUM = "file://LICENSE;md5=c3d807a85c09ebdff087f18b4969ff96 \ + file://png.h;startline=310;endline=424;md5=62968b88b0425ceeb919de3fd21b03e5" DEPENDS = "zlib" -PR = "r1" +PR = "r0" -SRC_URI = "${SOURCEFORGE_MIRROR}/project/libpng/libpng12/${PV}/libpng-${PV}.tar.bz2" +SRC_URI = "${SOURCEFORGE_MIRROR}/project/libpng/libpng12/${PV}/libpng-${PV}.tar.xz" -SRC_URI[md5sum] = "d5106b70b4f8b464a7da66bffe4565fb" -SRC_URI[sha256sum] = "fbf8faa70ebca2ed2ee6df6f2249f4722517b581af5b6c3c71bbdaf925d5954e" +SRC_URI[md5sum] = "a3e00fccbfe356174ab515b5c00641c7" +SRC_URI[sha256sum] = "4724f81f8c92ac7f360ad1fbf173396ea7c535923424db9fbaff07bfd9d8e8e7" inherit autotools binconfig pkgconfig ___ 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] [PATCH] udev 182: Create a symlink of /lib/udev/udevd in /sbin
On 11/27/2012 10:15 PM, Otavio Salvador wrote: On Tue, Nov 27, 2012 at 10:57 AM, Shakeel, Muhammad wrote: From: Muhammad Shakeel From udev 174 changelog: "The udev daemon moved to /lib/udev/udevd. Non-systemd init systems and non-dracut initramfs image generators need to change the init scripts. Alternatively the udev build needs to move udevd back to /sbin or create a symlink in /sbin, which is not done by default." Also for 64 bit architectures there exists /lib64/udev instead of /lib/udev and current init script fails to start udev. Signed-off-by: Muhammad Shakeel As far as I know, all code in master now handles it properly (the missing bits I sent a patch today) so why to include this symlink? I'm not sure about this. Two things: 1) Have we ever tested udev on a target where its ${base_libdir} is '/lib64'? Apparently, if udevd is intalled under '/lib64', its init script cannot start udev correctly. 2) Bug#2804 is related to to udev and ${base_libdir}. https://bugzilla.yoctoproject.org/show_bug.cgi?id=2804 (Some packages hardcode their udev rules directory to be '/lib/udev/rules.d/'. So can udev find them if the ${base_libdir} is '/lib64'? ) ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] what is "packagegroup-core-nfs-server"?
poking around core-image.bbclass, and noticed this: PACKAGE_GROUP_nfs-server = "packagegroup-core-nfs-server" except i don't see the corresponding packagegroup-core-nfs-server.bb recipe file. there *is* a packagegroup-core-nfs.bb file; how is the above processed? 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] what is "packagegroup-core-nfs-server"?
On 11/27/2012 08:18 PM, Robert P. J. Day wrote: poking around core-image.bbclass, and noticed this: PACKAGE_GROUP_nfs-server = "packagegroup-core-nfs-server" except i don't see the corresponding packagegroup-core-nfs-server.bb recipe file. there *is* a packagegroup-core-nfs.bb file; how is the above processed? It's defined in recipes-core/packagegroups/packagegroup-core-nfs.bb The line PACKAGES = "${PN}-server" provides the key you are looking for. Hope that helps. Sau! rday ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] RDEPENDS of packages created by PACKAGES_DYNAMIC not built before image rootfs
On Tue, 2012-11-27 at 15:07 -0600, Mark Hatle wrote: > On 11/27/12 2:23 PM, Martin Jansa wrote: > >> Bitbake doesn't know which modules this package will produce since its > >> using PACKAGES_DYNAMIC. It does its best effort to try and find DEPENDS > >> but it can't take the regexps and come up with > >> "pulseaudio-module-console-kit", hence it doesn't see the RDEPENDS. > >> There isn't any generic way we can teach it to do that either. If it > >> did, it would simply always build consolekit which you say you don't > >> want so its not relevant anyway. > >> > >> So basically, you need to decide whether you want consolekit enabled or > >> not and build accordingly, there is nothing you can do within bitbake to > >> "mind read" what the image is going to want... > > For the resolver, it has to use the RPROVIDES, PACKAGES and > PACKAGES_DYNAMIC... and it does to the limits that are reasonable... > > No, you know that you will need pulseaudio-module-console-kit because > > pulseaudio-server RDEPENDs on it (not on any pulseaudio-module-* but > > pulseaudio-module-console-kit exactly). So it's not really mind reading. > > But after the recipe has been built, the required item from PACKAGES_DYNAMIC > should now be in PACKAGES... and if it doesn't end up in the PACKAGES list, > it > would be a good idea to at a minimum trigger a warning... The catch is, is > there any way to tell if something from PACKAGES_DYNAMIC was used.. "After it is built" is no good to bitbake. It has to know what its doing without building things. All Bitbake can see is that there is some regexp in PACKAGES_DYNAMIC. Yes, Bitbake could take all the keys in the datastore, expand each one (since it could be constructed using another variable name) and find the ones starting with RDEPENDS, then apply the rexexp to each key and see if it matches. We one tried something like this and it is extremely slow, parsing would take a massive speed hit. The rule is therefore in corner cases like this (which are rather unusual), you add something to DEPENDS and be done with it. It is not a reasonable expectation for bitbake to figure this kind of thing out. I agree that if it builds things and discovers some kind of missing dependency, that would be good to tell the user about. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] RDEPENDS of packages created by PACKAGES_DYNAMIC not built before image rootfs
On Tue, 2012-11-27 at 21:23 +0100, Martin Jansa wrote: > On Tue, Nov 27, 2012 at 08:11:42PM +, Richard Purdie wrote: > > On Tue, 2012-11-27 at 16:41 +0100, Martin Jansa wrote: > > So basically, you need to decide whether you want consolekit enabled or > > not and build accordingly, there is nothing you can do within bitbake to > > "mind read" what the image is going to want... > > No, you know that you will need pulseaudio-module-console-kit because > pulseaudio-server RDEPENDs on it (not on any pulseaudio-module-* but > pulseaudio-module-console-kit exactly). So it's not really mind reading. Bitbake sees "pulseaudio-module-console-kit" and is has to ask "Which recipe provides this". To answer that question, it looks first at PACKAGES and then at PACKAGES_DYNAMIC. In this case it will find a match for PACKAGES_DYNAMIC but bitbake considers this a fuzzy match. We only match dynamic packages right at the end of processing and they are "fuzzy". Basically, they are just a sanity check in bitbake to ensure there is some chance of the thing getting built. I can see in this case that a dependency exists that BitBake could use to enhance its knowledge, the trouble is that is would have to first decide which provider is providing PACKAGES_DYNAMIC, and then search that package for extra RDEPENDS. In this case its "easier" since its all the same package but with our generic providers mechanism, this could just as easily be split between two recipes which makes the problem at lot more complex and the code has to be written for the general case. > If it's not possible with current code-base then we should document it > and add some work around in pulseaudio (I'm fine with building > consolekit even when it's not used later). I suspect we'll just have to add this. I agree it would be possible to try and figure out this corner case but whether its worth the complexity and extra parse time I'm not sure. The risk of adding further bugs trying to add this functionality would worry me, as would the extra complexity and the time taken to do it... As such I'd probably mark the bug report "LATER" and suggest working around this. If we were hitting this on many recipes, fine but we're not as far as I know. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] eglibc: always compile with optimization.
From: Jackie Huang eglibc fails to compile if someone tries to compile an entire image as -O0: error "glibc cannot be compiled without optimization" so in this case, force to use -O2 and give a note about it. [YOCTO #3405] Signed-off-by: Jackie Huang --- meta/recipes-core/eglibc/eglibc.inc | 11 +++ 1 files changed, 11 insertions(+), 0 deletions(-) diff --git a/meta/recipes-core/eglibc/eglibc.inc b/meta/recipes-core/eglibc/eglibc.inc index 3d136bf..1e04197 100644 --- a/meta/recipes-core/eglibc/eglibc.inc +++ b/meta/recipes-core/eglibc/eglibc.inc @@ -8,6 +8,17 @@ PATH_prepend = "${STAGING_BINDIR_TOOLCHAIN}.${STAGINGCC}:" TOOLCHAIN_OPTIONS = " --sysroot=${STAGING_DIR_TCBOOTSTRAP}" +# eglibc can't be built without optimization, if someone tries to compile an +# entire image as -O0, we override it with -O2 here and give a note about it. +def get_optimization(d): +selected_optimization = d.getVar("SELECTED_OPTIMIZATION", True) +if base_contains("SELECTED_OPTIMIZATION", "-O0", "x", "", d) == "x": +bb.note("eglibc can't be built with -O0, -O2 will be used instead.") +return selected_optimization.replace("-O0", "-O2") +return selected_optimization + +SELECTED_OPTIMIZATION := "${@get_optimization(d)}" + # siteconfig.bbclass runs configure which needs a working compiler # For the compiler to work we need a working libc yet libc isn't # in the sysroots directory at this point. This means the libc.so -- 1.7.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] Revert "eglibc: always compile with optimization."
From: Jackie Huang This reverts commit 9ca1c6120fad5dcae1694e8e37331c1b903f1fd0. The fix is not version specific, so revert it and move the fix code to the .inc in the following commit. Signed-off-by: Jackie Huang --- meta/recipes-core/eglibc/eglibc_2.16.bb | 11 --- 1 files changed, 0 insertions(+), 11 deletions(-) diff --git a/meta/recipes-core/eglibc/eglibc_2.16.bb b/meta/recipes-core/eglibc/eglibc_2.16.bb index 71bcc30..aa9256c 100644 --- a/meta/recipes-core/eglibc/eglibc_2.16.bb +++ b/meta/recipes-core/eglibc/eglibc_2.16.bb @@ -87,17 +87,6 @@ EXTRA_OECONF = "--enable-kernel=${OLDEST_KERNEL} \ EXTRA_OECONF += "${@get_libc_fpu_setting(bb, d)}" -# eglibc can't be built without optimization, if someone tries to compile an -# entire image as -O0, we override it with -O2 here and give a note about it. -def get_optimization(d): -selected_optimization = d.getVar("SELECTED_OPTIMIZATION", True) -if base_contains("SELECTED_OPTIMIZATION", "-O0", "x", "", d) == "x": -bb.note("eglibc can't be built with -O0, -O2 will be used instead.") -return selected_optimization.replace("-O0", "-O2") -return selected_optimization - -SELECTED_OPTIMIZATION := "${@get_optimization(d)}" - do_unpack_append() { bb.build.exec_func('do_move_ports', d) } -- 1.7.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/2] eglibc: move the fix code for optimization isssue to .inc
From: Jackie Huang I made a patch against the eglibc_2.16.bb for the optimization issue two weeks ago, but it's not a version specific issue and we still keep the versions 2.13 and 2.15 (and not having the 2.16 yet), so it would be more appropriate to move the code to the .inc file. And we also want to cherry-pick this commit to our oe-core branch so I revert the previous one and make a new commit against the .inc file but I'm not sure if it is proper to do that. Please correct me if it is not, thanks! * Test info: 1) MACHINE=qemux86-64/qemuppc/qemumips $ bitbake core-image-sato $ bitbake eglibc 2) MACHINE=qemux86-64/qemuppc/qemumips DEBUG_OPTIMIZATION = "-O0 -fno-omit-frame-pointer ${DEBUG_FLAGS} -pipe" DEBUG_BUILD = "1" or SELECTED_OPTIMIZATION = "${DEBUG_OPTIMIZATION}" $ bitbake core-image-sato $ bitbake eglibc The following changes since commit 764cc1eb3043c84121f597d2271108b91052095e: bitbake.conf: Change build output message to list BUILD_SYS, TARGET_SYS and NATIVELSBSTRING (2012-11-27 08:57:39 +) are available in the git repository at: git://git.pokylinux.org/poky-contrib jhuang0/d_eglibc_1128_1 http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=jhuang0/d_eglibc_1128_1 Jackie Huang (2): Revert "eglibc: always compile with optimization." eglibc: always compile with optimization. meta/recipes-core/eglibc/eglibc.inc | 11 +++ meta/recipes-core/eglibc/eglibc_2.16.bb | 11 --- 2 files changed, 11 insertions(+), 11 deletions(-) -- 1.7.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] what is "packagegroup-core-nfs-server"?
On Tue, 27 Nov 2012, Saul Wold wrote: > On 11/27/2012 08:18 PM, Robert P. J. Day wrote: > > > >poking around core-image.bbclass, and noticed this: > > > > PACKAGE_GROUP_nfs-server = "packagegroup-core-nfs-server" > > > > except i don't see the corresponding packagegroup-core-nfs-server.bb > > recipe file. there *is* a packagegroup-core-nfs.bb file; how is the > > above processed? > > > It's defined in recipes-core/packagegroups/packagegroup-core-nfs.bb > > The line > PACKAGES = "${PN}-server" > provides the key you are looking for. ah, quite so, thanks. i figured it was something obvious. 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] [PATCH] gcc-cross: Explicitly depend on linux-libc-headers
On Tue, 2012-11-27 at 20:08 +, McClintock Matthew-B29882 wrote: > On Thu, Nov 22, 2012 at 3:36 PM, Richard Purdie > wrote: > > gcc-cross cannot build without linux-libc-headers but doesn't explicitly > > depend on > > it relying on the implied dependency through libc. With cases where pieces > > can be installed through sstate, we now need this explicit dependency to > > ensure builds with partial sstate work. > > > > Signed-off-by: Richard Purdie > > --- > > diff --git a/meta/recipes-devtools/gcc/gcc-cross.inc > > b/meta/recipes-devtools/gcc/gcc-cross.inc > > index 6d160d6..cde08ee 100644 > > --- a/meta/recipes-devtools/gcc/gcc-cross.inc > > +++ b/meta/recipes-devtools/gcc/gcc-cross.inc > > @@ -1,6 +1,6 @@ > > inherit cross > > > > -DEPENDS = "virtual/${TARGET_PREFIX}binutils > > virtual/${TARGET_PREFIX}libc-for-gcc ${NATIVEDEPS}" > > +DEPENDS = "virtual/${TARGET_PREFIX}binutils > > virtual/${TARGET_PREFIX}libc-for-gcc linux-libc-headers ${NATIVEDEPS}" > > How would you suggest not forcing a rebuild of all components if the > linux headers signature changes? During our normal development we > change Linux headers for things that would in no way effect gcc or > even libc. It's painful to watch a complete rebuild occur because of > this. > > Just have a different recipe for headers for some components? This is partly why our headers recipe is separate from the kernel and other parts of the system but that doesn't sound like its enough for you. The signatures code can support things like adding the recipe name to SIGGEN_EXCLUDERECIPES_ABISAFE to mark it as not being part of inter-task dependencies so perhaps do that? Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gst-meta-base: Make ximagesing optional on x11 DISTRO_FEATURE
On Sun, 2012-11-25 at 22:15 -0800, Saul Wold wrote: > If x11 is disabled from DISTRO_FEATURE we don't build the ximagesink > package, but it still becomes a dependency in the final image which > causes a failure > > Signed-off-by: Saul Wold > --- > .../gstreamer/gst-meta-base_0.10.bb|3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/meta/recipes-multimedia/gstreamer/gst-meta-base_0.10.bb > b/meta/recipes-multimedia/gstreamer/gst-meta-base_0.10.bb > index 2fb39d5..0889437 100644 > --- a/meta/recipes-multimedia/gstreamer/gst-meta-base_0.10.bb > +++ b/meta/recipes-multimedia/gstreamer/gst-meta-base_0.10.bb > @@ -16,7 +16,10 @@ PACKAGES = "\ > > ALLOW_EMPTY = "1" > > +X11_RDEPENDS = "${@base_contains('DISTRO_FEATURES', 'x11', > 'gst-plugin-base-ximagesink', '', d)}" > + > RDEPENDS_gst-meta-base = "\ > +${X11_RDEPENDS} \ > gstreamer \ > gst-plugins-base-playbin \ > gst-plugins-base-decodebin \ This doesn't make sense, surely there would be some removal of a dependency as well as an addition? Looking at the recipe, the ximagesink dependency is already dependent on DISTRO_FEATURES and is in the gst-meta-x11-base package, not gst-meta-base? Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] libpng: update to upstream version 1.2.50
License md5sum changed only because libpng version numbers and release dates mentioned in it. Signed-off-by: Marko Lindqvist --- .../libpng/{libpng_1.2.49.bb => libpng_1.2.50.bb} | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) rename meta/recipes-multimedia/libpng/{libpng_1.2.49.bb => libpng_1.2.50.bb} (52%) diff --git a/meta/recipes-multimedia/libpng/libpng_1.2.49.bb b/meta/recipes-multimedia/libpng/libpng_1.2.50.bb similarity index 52% rename from meta/recipes-multimedia/libpng/libpng_1.2.49.bb rename to meta/recipes-multimedia/libpng/libpng_1.2.50.bb index d33a9f5..211e357 100644 --- a/meta/recipes-multimedia/libpng/libpng_1.2.49.bb +++ b/meta/recipes-multimedia/libpng/libpng_1.2.50.bb @@ -3,15 +3,15 @@ DESCRIPTION = "PNG Library" HOMEPAGE = "http://www.libpng.org/"; SECTION = "libs" LICENSE = "Libpng" -LIC_FILES_CHKSUM = "file://LICENSE;md5=20110633230abd47fe8680afa75f1492 \ - file://png.h;startline=308;endline=422;md5=edd1c552386a8c3773d90e278ae30891" +LIC_FILES_CHKSUM = "file://LICENSE;md5=c3d807a85c09ebdff087f18b4969ff96 \ + file://png.h;startline=310;endline=424;md5=62968b88b0425ceeb919de3fd21b03e5" DEPENDS = "zlib" -PR = "r1" +PR = "r0" -SRC_URI = "${SOURCEFORGE_MIRROR}/project/libpng/libpng12/${PV}/libpng-${PV}.tar.bz2" +SRC_URI = "${SOURCEFORGE_MIRROR}/project/libpng/libpng12/${PV}/libpng-${PV}.tar.xz" -SRC_URI[md5sum] = "d5106b70b4f8b464a7da66bffe4565fb" -SRC_URI[sha256sum] = "fbf8faa70ebca2ed2ee6df6f2249f4722517b581af5b6c3c71bbdaf925d5954e" +SRC_URI[md5sum] = "a3e00fccbfe356174ab515b5c00641c7" +SRC_URI[sha256sum] = "4724f81f8c92ac7f360ad1fbf173396ea7c535923424db9fbaff07bfd9d8e8e7" inherit autotools binconfig pkgconfig -- 1.7.10.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] local.conf.sample: Enable disk space monitoring by default
Running out of space is a serious issue and can corrupt the build. Since we can prevent it at minimal overhead, we might as well enable it by default. Signed-off-by: Richard Purdie --- diff --git a/meta/conf/local.conf.sample b/meta/conf/local.conf.sample index d181e75..859eb93 100644 --- a/meta/conf/local.conf.sample +++ b/meta/conf/local.conf.sample @@ -184,6 +184,22 @@ USER_CLASSES ?= "buildstats image-mklibs image-prelink" PATCHRESOLVE = "noop" # +# Disk Space Monitoring during the build +# +# Monitor the disk space during the build. If there is less that 1GB of space or less +# than 100K inodes in any key build location (TMPDIR, DL_DIR, SSTATE_DIR), gracefully +# shutdown the build. If there is less that 100MB or 1K inodes, perform a hard abort +# of the build. The reason for this is that running completely out of space can corrupt +# files and damages the build in ways which may not be easily recoverable. +BB_DISKMON_DIRS = "\ +STOPTASKS,${TMPDIR},1G,100K \ +STOPTASKS,${DL_DIR},1G,100K \ +STOPTASKS,${SSTATE_DIR},1G,100K \ +ABORT,${TMPDIR},100M,1K \ +ABORT,${DL_DIR},100M,1K \ +ABORT,${SSTATE_DIR},100M,1K" + +# # Shared-state files from other locations # # As mentioned above, shared state files are prebuilt cache data objects which can ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/2] eglibc: move the fix code for optimization isssue to .inc
On Wed, 2012-11-28 at 14:11 +0800, jackie.hu...@windriver.com wrote: > From: Jackie Huang > > I made a patch against the eglibc_2.16.bb for the optimization issue two > weeks ago, > but it's not a version specific issue and we still keep the versions 2.13 and > 2.15 > (and not having the 2.16 yet), so it would be more appropriate to move the > code to > the .inc file. > And we also want to cherry-pick this commit to our oe-core branch so I revert > the > previous one and make a new commit against the .inc file but I'm not sure if > it is > proper to do that. Please correct me if it is not, thanks! > > * Test info: > 1) MACHINE=qemux86-64/qemuppc/qemumips > $ bitbake core-image-sato > $ bitbake eglibc > > 2) MACHINE=qemux86-64/qemuppc/qemumips >DEBUG_OPTIMIZATION = "-O0 -fno-omit-frame-pointer ${DEBUG_FLAGS} -pipe" >DEBUG_BUILD = "1" or SELECTED_OPTIMIZATION = "${DEBUG_OPTIMIZATION}" > $ bitbake core-image-sato > $ bitbake eglibc > > The following changes since commit 764cc1eb3043c84121f597d2271108b91052095e: > > bitbake.conf: Change build output message to list BUILD_SYS, TARGET_SYS and > NATIVELSBSTRING (2012-11-27 08:57:39 +) > > are available in the git repository at: > git://git.pokylinux.org/poky-contrib jhuang0/d_eglibc_1128_1 > > http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=jhuang0/d_eglibc_1128_1 > > Jackie Huang (2): > Revert "eglibc: always compile with optimization." > eglibc: always compile with optimization. I've queued this on master-next. I changed it from two commits to one commit which just moves the code for the reason you describe. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core