[OE-core] [PATCH] qemu.inc: Fix typo for KERNEL_FEATURES

[Saul Wold]

Thans to Bjorn Arnelid for finding this

Cc: bjorn.arne...@xdin.com

[YOCTO #5173]

Signed-off-by: Saul Wold 
---
 meta/conf/machine/include/qemu.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/conf/machine/include/qemu.inc 
b/meta/conf/machine/include/qemu.inc
index a78622d..855 100644
--- a/meta/conf/machine/include/qemu.inc
+++ b/meta/conf/machine/include/qemu.inc
@@ -26,4 +26,4 @@ PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
 EXTRA_IMAGEDEPENDS += "qemu-native qemu-helper-native"
 
 # Provide the nfs server kernel module for all qemu images
-KERNEL_FEATURES_append_pn-linux-yocto = " features/nfsd/nfsd-enable.scc"
+KERNEL_FEATURES_append_pn_linux-yocto = " features/nfsd/nfsd-enable.scc"
-- 
1.8.3.1

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] GCC search paths in MinGW SDK

[Khem Raj]

On Sep 3, 2013, at 6:45 PM, Mark Hatle  wrote:

> On 9/3/13 4:13 PM, Francois Retief wrote:
>> Hi all,
>> 
>> Thanks to Richard's recent improvements in the oe-core tree, I finally got my
>> first MinGW build to compile through and generate a SDK tarball.
>> 
>> Next issue is that on windows GCC is unable to find the crt1.o, crti.o and
>> crtbegin.o files. when compiling a small hello world app (see gist
>> 
>> [1] for gcc verbose output). I verified that the files are indeed in the SDK
>> folders and was correctly unpacked.
>> 
>> Next, I checked the search path (-L) options and they point to the respective
>> directories where the files reside.
>> 
>> Is it hard coded somewhere GCC should look for these files?  Can anyone give 
>> me
>> some pointers where to start looking?

are you passing correct --sysroot option to gcc ?

> 
> Usually GCC can learn the location where it was executed from, and then use a 
> relative path from that to the location where the libc and other components 
> are located.


are you talking about GCC_EXEC_PREFIX ?
> 
>> Cheers,
>>   Francois
>> 
>> ps. I have noticed that there is a relocate_sdk.py file in the root of the 
>> SDK
>> folder. What is it's purpose and can it have anything to do with the GCC 
>> search
>> paths?
> 
> On linux we play with the RPATH and other components to ensure that the 
> executables can file the libraries for execution.  I don't believe that is a 
> problem on windows as the DLLs are searched automatically.
> 
> --Mark
> 
>> [1]
>> https://gist.github.com/fgretief/6429416#file-mingw-gcc-verbose-output-2013-09-03
>> [2] https://github.com/fgretief/meta-mingw
>> 
>> 
>> 
>> ___
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>> 
> 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 4/4] util-linux: move su to /bin for lsb command check test

[Hongxu Jia]

In busybox, util-linux and shadow, su has been moved to /usr/bin/,
but lsb cmdchk needs su in /bin.

Move su to /bin could fix this issue.

[YOCTO#5175]

Signed-off-by: Hongxu Jia 
---
 meta/recipes-core/util-linux/util-linux.inc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-core/util-linux/util-linux.inc 
b/meta/recipes-core/util-linux/util-linux.inc
index 8a14d16..15b6770 100644
--- a/meta/recipes-core/util-linux/util-linux.inc
+++ b/meta/recipes-core/util-linux/util-linux.inc
@@ -129,7 +129,7 @@ do_install () {
 sbinprogs="agetty ctrlaltdel cfdisk vipw vigr"
 sbinprogs_a="pivot_root hwclock mkswap mkfs.minix fsck.minix losetup 
swapon swapoff fdisk readprofile fsck blkid blockdev"
 usrbinprogs_a="chfn chsh hexdump last logger mesg newgrp renice 
utmpdump wall setsid chrt flock getopt"
-binprogs_a="dmesg kill more umount mount login reset"
+binprogs_a="dmesg kill more umount mount login reset su"
 
 if [ "${base_sbindir}" != "${sbindir}" ]; then
mkdir -p ${D}${base_sbindir}
@@ -224,6 +224,6 @@ BBCLASSEXTEND = "native nativesdk"
 python do_package_prepend () {
 if '--enable-su' in d.getVar('EXTRA_OECONF', True).split():
 alt_name = "su"
-d.setVarFlag('ALTERNATIVE_LINK_NAME', alt_name, '%s/%s' % 
(d.getVar('bindir', True), alt_name))
+d.setVarFlag('ALTERNATIVE_LINK_NAME', alt_name, '%s/%s' % 
(d.getVar('base_bindir', True), alt_name))
 d.appendVar('ALTERNATIVE_%s' % (d.getVar('PN', True)), ' ' + alt_name)
 }
-- 
1.8.1.2

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 2/4] busybox: move su to /bin for lsb command check test

[Hongxu Jia]

In busybox, util-linux and shadow, su has been moved to /usr/bin/,
but lsb cmdchk needs su in /bin.

Move su to /bin could fix this issue.

[YOCTO #5175]

Signed-off-by: Hongxu Jia 
---
 .../busybox/busybox-1.21.1/su-usr-bin.patch| 26 --
 meta/recipes-core/busybox/busybox_1.21.1.bb|  1 -
 2 files changed, 27 deletions(-)
 delete mode 100644 meta/recipes-core/busybox/busybox-1.21.1/su-usr-bin.patch

diff --git a/meta/recipes-core/busybox/busybox-1.21.1/su-usr-bin.patch 
b/meta/recipes-core/busybox/busybox-1.21.1/su-usr-bin.patch
deleted file mode 100644
index 0d5b558..000
--- a/meta/recipes-core/busybox/busybox-1.21.1/su-usr-bin.patch
+++ /dev/null
@@ -1,26 +0,0 @@
-busybox: move /bin/su to /usr/bin/su to match util-linux and shadow
-
-Both of util-linux and shadow have su binary in /usr/bin, fix busybox
-to use the same path so they can be properly tracked by alternatives.
-
-Upstream-Status: Inappropriate [embedded]
-Signed-off-by: Hongxu Jia 

- include/applets.src.h | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/include/applets.src.h b/include/applets.src.h
 a/include/applets.src.h
-+++ b/include/applets.src.h
-@@ -349,7 +349,7 @@ IF_STAT(APPLET(stat, BB_DIR_USR_BIN, BB_SUID_DROP))
- IF_STRINGS(APPLET(strings, BB_DIR_USR_BIN, BB_SUID_DROP))
- IF_STTY(APPLET(stty, BB_DIR_BIN, BB_SUID_DROP))
- /* Needs to be run by root or be suid root - needs to change uid and gid: */
--IF_SU(APPLET(su, BB_DIR_BIN, BB_SUID_REQUIRE))
-+IF_SU(APPLET(su, BB_DIR_USR_BIN, BB_SUID_REQUIRE))
- IF_SULOGIN(APPLET(sulogin, BB_DIR_SBIN, BB_SUID_DROP))
- IF_SUM(APPLET(sum, BB_DIR_USR_BIN, BB_SUID_DROP))
- IF_SV(APPLET(sv, BB_DIR_USR_BIN, BB_SUID_DROP))
--- 
-1.8.1.2
-
diff --git a/meta/recipes-core/busybox/busybox_1.21.1.bb 
b/meta/recipes-core/busybox/busybox_1.21.1.bb
index 784c924..44e507e 100644
--- a/meta/recipes-core/busybox/busybox_1.21.1.bb
+++ b/meta/recipes-core/busybox/busybox_1.21.1.bb
@@ -23,7 +23,6 @@ SRC_URI = 
"http://www.busybox.net/downloads/busybox-${PV}.tar.bz2;name=tarball \
file://umount.busybox \
file://defconfig \
file://stat-usr-bin.patch \
-   file://su-usr-bin.patch \
file://busybox-syslog.service.in \
file://busybox-klogd.service.in \
file://testsuite-du-du-k-works-fix-false-positive.patch \
-- 
1.8.1.2

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 0/4] fix LSB Command Check failed

[Hongxu Jia]

*Problem
LSB Command Check failed
...
su 1 failed
install_initd 1 failed
remove_initd 1 failed
...

The journal shows the command didsn't exist.
...
Looking for command su
Looking for command install_initd
Looking for command remove_initd
...

//Hongxu

The following changes since commit 1b814498b60d5f354d8cc5bdf568b91baf0745dc:

  bitbake: bitbake/cooker: fix some calls of cookerdata.findConfigFile method 
(2013-09-02 12:26:20 +0100)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib hongxu/fix-lsb-cmdchek
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=hongxu/fix-lsb-cmdchek

Hongxu Jia (4):
  LSB Command Check: fix install_initd and remove_initd not found
  busybox: move su to /bin for lsb command check test
  shadow: move su to /bin for lsb command check test
  util-linux: move su to /bin for lsb command check test

 .../busybox/busybox-1.21.1/su-usr-bin.patch| 26 --
 meta/recipes-core/busybox/busybox_1.21.1.bb|  1 -
 meta/recipes-core/util-linux/util-linux.inc|  4 ++--
 .../recipes-extended/chkconfig/chkconfig_1.3.58.bb |  4 ++--
 meta/recipes-extended/lsb/lsb_4.1.bb   |  4 ++--
 meta/recipes-extended/shadow/shadow_4.1.4.3.bb |  3 ++-
 6 files changed, 8 insertions(+), 34 deletions(-)
 delete mode 100644 meta/recipes-core/busybox/busybox-1.21.1/su-usr-bin.patch

-- 
1.8.1.2

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/4] LSB Command Check: fix install_initd and remove_initd not found

[Hongxu Jia]

The install_initd and remove_initd are linked to /sbin/chkconfig for lsb
core test, and chkconfig has been moved from /sbin to /usr/sbin in order
to fix QA warning about unsafe references in binaries.
(In commit e486242db83297701803866bea971a2f1a1135fe)

Let install_initd and remove_initd link to /usr/sbin/chkconfig could fix
this issue.

[YOCTO #5152]

Signed-off-by: Hongxu Jia 
---
 meta/recipes-extended/chkconfig/chkconfig_1.3.58.bb | 4 ++--
 meta/recipes-extended/lsb/lsb_4.1.bb| 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta/recipes-extended/chkconfig/chkconfig_1.3.58.bb 
b/meta/recipes-extended/chkconfig/chkconfig_1.3.58.bb
index c6f8b1d..38c3cdf 100644
--- a/meta/recipes-extended/chkconfig/chkconfig_1.3.58.bb
+++ b/meta/recipes-extended/chkconfig/chkconfig_1.3.58.bb
@@ -50,8 +50,8 @@ do_install() {
 
 do_install_append_linuxstdbase() {
install -d ${D}${libdir}/lsb/
-   ln -sf ${base_sbindir}/chkconfig ${D}/${libdir}/lsb/install_initd
-   ln -sf ${base_sbindir}/chkconfig ${D}/${libdir}/lsb/remove_initd
+   ln -sf ${sbindir}/chkconfig ${D}/${libdir}/lsb/install_initd
+   ln -sf ${sbindir}/chkconfig ${D}/${libdir}/lsb/remove_initd
 }
 
 PACKAGES =+ "${PN}-alternatives ${PN}-alternatives-doc"
diff --git a/meta/recipes-extended/lsb/lsb_4.1.bb 
b/meta/recipes-extended/lsb/lsb_4.1.bb
index 59d5bca..c80ff59 100644
--- a/meta/recipes-extended/lsb/lsb_4.1.bb
+++ b/meta/recipes-extended/lsb/lsb_4.1.bb
@@ -79,8 +79,8 @@ do_install_append(){
 
# creat links for LSB test
install -d ${D}/${libdir}/lsb
-   ln -sf ${base_sbindir}/chkconfig ${D}/${libdir}/lsb/install_initd
-   ln -sf ${base_sbindir}/chkconfig ${D}/${libdir}/lsb/remove_initd
+   ln -sf ${sbindir}/chkconfig ${D}/${libdir}/lsb/install_initd
+   ln -sf ${sbindir}/chkconfig ${D}/${libdir}/lsb/remove_initd
ln -sf ${sbindir}/sendmail ${D}/${libdir}/sendmail
 
if [ "${TARGET_ARCH}" = "x86_64" ];then
-- 
1.8.1.2

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 3/4] shadow: move su to /bin for lsb command check test

[Hongxu Jia]

In busybox, util-linux and shadow, su has been moved to /usr/bin/,
but lsb cmdchk needs su in /bin.

Move su to /bin could fix this issue.

[YOCTO#5175]

Signed-off-by: Hongxu Jia 
---
 meta/recipes-extended/shadow/shadow_4.1.4.3.bb | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-extended/shadow/shadow_4.1.4.3.bb 
b/meta/recipes-extended/shadow/shadow_4.1.4.3.bb
index 31cef20..3abb325 100644
--- a/meta/recipes-extended/shadow/shadow_4.1.4.3.bb
+++ b/meta/recipes-extended/shadow/shadow_4.1.4.3.bb
@@ -113,6 +113,7 @@ do_install() {
fi
if [ "${bindir}" != "${base_bindir}" ]; then
mv ${D}${bindir}/login ${D}${base_bindir}/login
+   mv ${D}${bindir}/su ${D}${base_bindir}/su
fi
 
# Handle link properly after rename, otherwise missing files would
@@ -129,7 +130,7 @@ ALTERNATIVE_LINK_NAME[chpasswd] = "${sbindir}/chpasswd"
 ALTERNATIVE_LINK_NAME[login] = "${base_bindir}/login"
 ALTERNATIVE_LINK_NAME[vipw] = "${base_sbindir}/vipw"
 ALTERNATIVE_LINK_NAME[vigr] = "${base_sbindir}/vigr"
-ALTERNATIVE_LINK_NAME[su] = "${bindir}/su"
+ALTERNATIVE_LINK_NAME[su] = "${base_bindir}/su"
 
 pkg_postinst_${PN} () {
if [ "x$D" != "x" ]; then
-- 
1.8.1.2

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] elfutils-native: Fix build on distros with gcc 4.8

[Khem Raj]

The patch redhat-portability.diff causes this issue
so lets revert the portion which was using %a instead of %m
thats recommended anyway, redhat patch seems to be targetting
old compilers.

Signed-off-by: Khem Raj 
---
 .../elfutils/elfutils/fix-build-gcc-4.8.patch  | 44 ++
 meta/recipes-devtools/elfutils/elfutils_0.155.bb   |  3 +-
 2 files changed, 45 insertions(+), 2 deletions(-)
 create mode 100644 
meta/recipes-devtools/elfutils/elfutils/fix-build-gcc-4.8.patch

diff --git a/meta/recipes-devtools/elfutils/elfutils/fix-build-gcc-4.8.patch 
b/meta/recipes-devtools/elfutils/elfutils/fix-build-gcc-4.8.patch
new file mode 100644
index 000..a7c3519
--- /dev/null
+++ b/meta/recipes-devtools/elfutils/elfutils/fix-build-gcc-4.8.patch
@@ -0,0 +1,44 @@
+This patch fixes a warning seen with gcc 4.8 (especially on ubuntu 13.10)
+
+| addr2line.c: In function 'handle_address':
+| addr2line.c:450:7: error: format '%a' expects argument of type 'float *', 
but argument 3 has type 'char **' [-Werror=format=]
+|if (sscanf (string, "(%a[^)])%" PRIiMAX "%n", &name, &addr, &i) == 2
+|^
+| addr2line.c:453:7: error: format '%a' expects argument of type 'float *', 
but argument 3 has type 'char **' [-Werror=format=]
+|switch (sscanf (string, "%a[^-+]%n%" PRIiMAX "%n", &name, &i, &addr, 
&j))
+|^
+| cc1: all warnings being treated as errors
+
+
+%a is old GNU style and should be abandoned in favor of %m
+
+Also see
+
+http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54361
+
+to support this assertion
+
+This patch is added via redhat-compatibility patch so lets revert this part
+here.
+
+Signed-off-by: Khem Raj 
+
+Upstream-Status: Inappropriate [Caused by an earlier patch]
+
+Index: elfutils-0.155/src/addr2line.c
+===
+--- elfutils-0.155.orig/src/addr2line.c
 elfutils-0.155/src/addr2line.c
+@@ -447,10 +447,10 @@ handle_address (const char *string, Dwfl
+   bool parsed = false;
+   int i, j;
+   char *name = NULL;
+-  if (sscanf (string, "(%a[^)])%" PRIiMAX "%n", &name, &addr, &i) == 2
++  if (sscanf (string, "(%m[^)])%" PRIiMAX "%n", &name, &addr, &i) == 2
+ && string[i] == '\0')
+   parsed = adjust_to_section (name, &addr, dwfl);
+-  switch (sscanf (string, "%a[^-+]%n%" PRIiMAX "%n", &name, &i, &addr, 
&j))
++  switch (sscanf (string, "%m[^-+]%n%" PRIiMAX "%n", &name, &i, &addr, 
&j))
+   {
+   default:
+ break;
diff --git a/meta/recipes-devtools/elfutils/elfutils_0.155.bb 
b/meta/recipes-devtools/elfutils/elfutils_0.155.bb
index c5a2f0e..1a8c3c7 100644
--- a/meta/recipes-devtools/elfutils/elfutils_0.155.bb
+++ b/meta/recipes-devtools/elfutils/elfutils_0.155.bb
@@ -5,8 +5,6 @@ LICENSE = "(GPLv3 & Elfutils-Exception)"
 LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
 DEPENDS = "libtool bzip2 zlib virtual/libintl"
 
-PR = "r0"
-
 SRC_URI = 
"https://fedorahosted.org/releases/e/l/elfutils/${PV}/elfutils-${PV}.tar.bz2";
 
 SRC_URI[md5sum] = "163a5712b86f6bdfebdf233cc6e2192d"
@@ -24,6 +22,7 @@ SRC_URI += "\
file://dso-link-change.patch \
file://nm-Fix-size-passed-to-snprintf-for-invalid-sh_name-case.patch \
file://elfutils-ar-c-fix-num-passed-to-memset.patch \
+   file://fix-build-gcc-4.8.patch \
 "
 # Only apply when building uclibc based target recipe
 SRC_URI_append_libc-uclibc = " file://uclibc-support.patch"
-- 
1.8.3.2

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 5/5] grub-efi.bbclass: Add serial and graphics menu options

[Darren Hart]

On Thu, 2013-09-12 at 12:19 -0500, Jason Wessel wrote:
> The syslinux.bbclass already has support for automatically generated
> serial and graphics menu choices.  This patch adds the same concept to
> the grub-efi menu.  That makes it possible to generate a single image
> which can boot on a PCBIOS or EFI firmware with consistent looking
> boot options.
> 
> [YOCTO #4100]
> 
> Signed-off-by: Jason Wessel 
> ---
>  meta/classes/grub-efi.bbclass |   41 
> -
>  meta/conf/machine/qemux86-64.conf |2 +-
>  meta/conf/machine/qemux86.conf|2 ++
>  3 files changed, 30 insertions(+), 15 deletions(-)
> 
> diff --git a/meta/classes/grub-efi.bbclass b/meta/classes/grub-efi.bbclass
> index c6f5d4e..c07e4a1 100644
> --- a/meta/classes/grub-efi.bbclass
> +++ b/meta/classes/grub-efi.bbclass
> @@ -9,6 +9,7 @@
>  # External variables
>  # ${INITRD} - indicates a filesystem image to use as an initrd (optional)
>  # ${ROOTFS} - indicates a filesystem image to include as the root filesystem 
> (optional)
> +# ${GRUB_GFXSERIAL} - set this to 1 to have graphics and serial in the boot 
> menu
>  # ${LABELS} - a list of targets for the automatic config
>  # ${APPEND} - an override list of append strings for each label
>  # ${GRUB_OPTS} - additional options to add to the config, ';' delimited # 
> (optional)
> @@ -16,6 +17,7 @@
>  
>  do_bootimg[depends] += "grub-efi-${TRANSLATED_TARGET_ARCH}-native:do_deploy"
>  
> +GRUB_SERIAL ?= "console=ttyS0,115200"
>  GRUBCFG = "${S}/grub.cfg"
>  GRUB_TIMEOUT ?= "10"
>  #FIXME: build this from the machine config
> @@ -55,6 +57,8 @@ python build_grub_cfg() {
>  bb.error("WORKDIR not defined, unable to package")
>  return
>  
> +gfxserial = d.getVar('GRUB_GFXSERIAL', True) or ""
> +
>  labels = d.getVar('LABELS', True)
>  if not labels:
>  bb.debug(1, "LABELS not defined, nothing to do")
> @@ -88,6 +92,12 @@ python build_grub_cfg() {
>  else:
>  cfgfile.write('timeout=50\n')
>  
> +if gfxserial == "1":
> +btypes = [ [ " graphics console", "console=tty0" ],
> +[ " serial console", d.getVar('GRUB_SERIAL', True) or "" ] ]
> +else:
> +btypes = [ [ "", "" ] ]
> +
>  for label in labels.split():
>  localdata = d.createCopy()
>  
> @@ -95,24 +105,27 @@ python build_grub_cfg() {
>  if not overrides:
>  raise bb.build.FuncFailed('OVERRIDES not defined')
>  
> -localdata.setVar('OVERRIDES', label + ':' + overrides)
> -bb.data.update_data(localdata)
> +for btype in btypes:
> +localdata.setVar('OVERRIDES', label + ':' + overrides)
> +bb.data.update_data(localdata)
>  
> -cfgfile.write('\nmenuentry \'%s\'{\n' % (label))
> -if label == "install":
> -label = "install-efi"
> -cfgfile.write('linux /vmlinuz LABEL=%s' % (label))
> +cfgfile.write('\nmenuentry \'%s%s\'{\n' % (label, btype[0]))
> +lb = label
> +if label == "install":
> +lb = "install-efi"
> +cfgfile.write('linux /vmlinuz LABEL=%s' % (lb))
>  
> -append = localdata.getVar('APPEND', True)
> -initrd = localdata.getVar('INITRD', True)
> +append = localdata.getVar('APPEND', True)
> +initrd = localdata.getVar('INITRD', True)
>  
> -if append:
> -cfgfile.write('%s' % (append))
> -cfgfile.write('\n')
> +if append:
> +cfgfile.write('%s' % (append))
> +cfgfile.write(' %s' % btype[1])
> +cfgfile.write('\n')
>  
> -if initrd:
> -cfgfile.write('initrd /initrd')
> -cfgfile.write('\n}\n')
> +if initrd:
> +cfgfile.write('initrd /initrd')
> +cfgfile.write('\n}\n')
>  
>  cfgfile.close()
>  }

I'm not very familiar with the cfgfile for menus and such, so I don't
have much to add. The one thing that catches me by surprise is the need
for the serial device. On EFI systems, grub here uses the EFI console
service, so if that uses the serial port you get it for free, no need
for GRUB to try and use it directly. In fact does the above not
cause some kind of conflict between the EFI console service and grub
serial?

Both of the following should be in a separate patch. In fact, they
should probably have a qemux86-common.inc which took care of most of
this (as was done recently for genericx86-common.inc).

> diff --git a/meta/conf/machine/qemux86-64.conf 
> b/meta/conf/machine/qemux86-64.conf
> index c572225..6f68410 100644
> --- a/meta/conf/machine/qemux86-64.conf
> +++ b/meta/conf/machine/qemux86-64.conf
> @@ -21,6 +21,6 @@ XSERVER = "xserver-xorg \
> xf86-input-evdev \
> xf86-video-vmware"
>  
> -MACHINE_FEATURES += "x86"
> +MACHINE_FEATURES += "x86 efi"
>  
>  MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "v86d"
> diff --git a/meta/conf/machine/qemux86.conf 

Re: [OE-core] [PATCH] bitbake.conf: include machine name in DEPLOY_DIR_IMAGE

[Richard Purdie]

On Thu, 2013-09-12 at 08:47 -0700, Flanagan, Elizabeth wrote:
> This will need a LAYERVERSION_core bump for autobuilder compatibility.
I've queued on in master-next along with this patch.

Cheers,

Richard

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 0/1] image.bbclass: do not automatically remove update-rc.d

[Qi.Chen]

From: Chen Qi 

The following changes since commit bd76847d867f9f76f76f033439cfb834cf59380f:

  libnewt-python: Don't write a whiptail package (2013-09-12 08:23:42 +0100)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib ChenQi/do-not-remove-updatercd
  
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/do-not-remove-updatercd

Chen Qi (1):
  image.bbclass: do not automatically remove update-rc.d

 meta/classes/image.bbclass |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

-- 
1.7.9.5

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/1] image.bbclass: do not automatically remove update-rc.d

[Qi.Chen]

From: Chen Qi 

In rootfs_uninstall_unneeded function, the update-rc.d package would
be removed if no 'package-management' and no delayed postinsts.

However, in update-rc.d.bbclass, the update-rc.d package is only
recommended. Thus, if NO_RECOMMENDATIONS is enabled or 'update-rc.d'
is added to BAD_RECOMMENDATIONS, the update-rc.d package will not
be installed at the first place. Tring to remove it will result in an
error.

Also this function assumes that update-rc.d is only used by postinsts.
This assumption isn't always true. Users may want to write their own
init scripts and use the update-rc.d tool to manage them.

[YOCTO #5169]

Signed-off-by: Chen Qi 
---
 meta/classes/image.bbclass |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index f1e62f14..f37cd90 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -505,12 +505,12 @@ rootfs_uninstall_unneeded () {
if ${@base_contains("IMAGE_FEATURES", "package-management", "false", 
"true", d)}; then
if [ -z "$(delayed_postinsts)" ]; then
# All packages were successfully configured.
-   # update-rc.d, base-passwd, run-postinsts are no 
further use, remove them now
+   # base-passwd, run-postinsts are no further use, remove 
them now
remove_run_postinsts=false
if [ -e 
${IMAGE_ROOTFS}${sysconfdir}/init.d/run-postinsts ]; then
remove_run_postinsts=true
fi
-   rootfs_uninstall_packages update-rc.d base-passwd 
${ROOTFS_BOOTSTRAP_INSTALL}
+   rootfs_uninstall_packages base-passwd 
${ROOTFS_BOOTSTRAP_INSTALL}
 
# Need to remove rc.d files for run-postinsts by hand 
since opkg won't
# call postrm scripts in offline root mode.
-- 
1.7.9.5

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] update-rc.d.bbclass: change RRECOMMENDS to RDEPENDS

[ChenQi]

On 09/12/2013 08:18 PM, Martin Jansa wrote:

On Thu, Sep 12, 2013 at 07:18:12PM +0800, ChenQi wrote:

On 09/12/2013 06:25 PM, Martin Jansa wrote:

On Thu, Sep 12, 2013 at 05:43:55PM +0800, qi.c...@windriver.com wrote:

From: Chen Qi 

If a package inherits update-rc.d.bbclass, it actually needs it to
update the symlinks under /etc/rc?.d/ directories. This is a runtime
dependency. For example, if we try to upgrade the dropbear on target,
its postinst process will need the update-rc.d utility available,
otherwise, the upgrade process will fail.

Besides, if we only recommend update-rc.d, the do_rootfs process will
fail once NO_RRECOMMENDATIONS is enabled. Because in OE, we try to do
the postinsts at rootfs time.

IIRC it was changed to allow systemd images to be built completely
without update-rc.d (with BAD_RECOMMENDATIONS += "update-rc.d") and it's
IMHO still valid use-case as update-rc.d is inherited even when systemd
is used.


Now that the 'rm_sysvinit_initdir' function has been added to the
systemd.bbclass, I think we can safely use RDEPENDS here. Because
1) If the /etc/init is removed, update-rc.d command in postinst has no
real effect.
2) If the /etc/init is not removed, that means symlinks under
/etc/rc?.d/ should be set up.

So I think there's no negative effect if update-rc.d is installed in
case of a systemd system.

Also, I don't think adding update-rc.d to BAD_RECOMMENDATIONS is a good
idea.
For example, we have a systemd based image running and we are installing
a new package to that image. That package has an init script but no
corresponding service file. If we only recommend update-rc.d and it's in
BAD_RECOMMENDATIONS, the install process will fail. This is not what
user might expect.

So I'd like to suggest that we change it back to RDEPENDS.

commit 2c403979c03898c679c5a1e1092aec784dbeb77c
Author: Ross Burton 
Date:   Tue Mar 5 11:57:00 2013 +

update-rcd: drop depends to recommends, check for update-rcd in scripts

This class is still checking if update-rc.d is installed before using
it, so nothing should fail terribly if image developer decides that he
want's image without any sysvinit related stuff.

If you want image which supports both you can add runtime dependency on
update-rc.d somewhere else - it doesn't need to be pulled by every
recipe which inherits update-rc.d bbclass.


Thanks, Martin.

I think I made a mistake.
The real cause is that in image.bbclass, the rootfs_uninstall_unneeded 
function tries to remove the update-rc.d package but it's not installed 
because NO_RECOMMENDATIONS is enabled.

I'm gonna remove update-rc.d from the uninstall list in that function.
Patch will be sent out soon.

Thanks a lot,
Chen Qi



Best Regards,
Chen Qi


This patch fixes this problem by changing the RRECOMMENDS to RDEPENDS
to let the packages actually rdepend on update-rc.d.

[YOCTO #5169]

Signed-off-by: Chen Qi 
---
   meta/classes/update-rc.d.bbclass |2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/update-rc.d.bbclass b/meta/classes/update-rc.d.bbclass
index 5588569..3dee13a 100644
--- a/meta/classes/update-rc.d.bbclass
+++ b/meta/classes/update-rc.d.bbclass
@@ -6,7 +6,7 @@ UPDATERCD_virtclass-cross = ""
   UPDATERCD_class-native = ""
   UPDATERCD_class-nativesdk = ""
   
-RRECOMMENDS_${UPDATERCPN}_append = " ${UPDATERCD}"

+RDEPENDS_${UPDATERCPN}_append = " ${UPDATERCD}"
   
   INITSCRIPT_PARAMS ?= "defaults"
   
--

1.7.9.5

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] eglibc_2.18.bb: Fix IFUNC support for ARM REL relocations

[Khem Raj]

This should fix the case where neon code is emitted for machines
which dont have neon unit in the chip

[YOCTO# 5161]

Signed-off-by: Khem Raj 
---
 .../0001-ARM-Pass-dl_hwcap-to-IFUNC-resolver.patch | 43 ++
 meta/recipes-core/eglibc/eglibc_2.18.bb|  1 +
 2 files changed, 44 insertions(+)
 create mode 100644 
meta/recipes-core/eglibc/eglibc-2.18/0001-ARM-Pass-dl_hwcap-to-IFUNC-resolver.patch

diff --git 
a/meta/recipes-core/eglibc/eglibc-2.18/0001-ARM-Pass-dl_hwcap-to-IFUNC-resolver.patch
 
b/meta/recipes-core/eglibc/eglibc-2.18/0001-ARM-Pass-dl_hwcap-to-IFUNC-resolver.patch
new file mode 100644
index 000..24d4772
--- /dev/null
+++ 
b/meta/recipes-core/eglibc/eglibc-2.18/0001-ARM-Pass-dl_hwcap-to-IFUNC-resolver.patch
@@ -0,0 +1,43 @@
+Upstream-Status: Backport
+
+From d0721e703d222c01a9e8c329311c4fb01dac6972 Mon Sep 17 00:00:00 2001
+From: Carlos O'Donell 
+Date: Thu, 29 Aug 2013 00:17:33 -0400
+Subject: [PATCH] ARM: Pass dl_hwcap to IFUNC resolver.
+
+For REL relocs pass dl_hwcap to the IFUNC resolver
+as is required by the IFUNC API (bug 15905).
+---
+ NEWS   | 2 +-
+ ports/ChangeLog.arm| 7 +++
+ ports/sysdeps/arm/dl-machine.h | 2 +-
+ 3 files changed, 9 insertions(+), 2 deletions(-)
+
+Index: libc/ports/ChangeLog.arm
+===
+--- libc.orig/ports/ChangeLog.arm  2013-07-14 16:08:52.0 -0700
 libc/ports/ChangeLog.arm   2013-09-12 17:17:24.174387150 -0700
+@@ -1,3 +1,10 @@
++2013-08-28  Kyle McMartin  
++  Carlos O'Donell  
++
++  [BZ #15905]
++  * sysdeps/arm/dl-machine [!RTLD_BOOTSTRAP] (elf_machine_rel):
++  Pass GLRO(dl_hwcap) to the IFUNC resolver.
++
+ 2013-07-03  Joseph Myers  
+ 
+   * sysdeps/arm/include/bits/setjmp.h [_ISOMAC] (JMP_BUF_REGLIST):
+Index: libc/ports/sysdeps/arm/dl-machine.h
+===
+--- libc.orig/ports/sysdeps/arm/dl-machine.h   2013-09-12 08:56:03.641743520 
-0700
 libc/ports/sysdeps/arm/dl-machine.h2013-09-12 17:17:24.174387150 
-0700
+@@ -503,7 +503,7 @@
+ break;
+   case R_ARM_IRELATIVE:
+ value = map->l_addr + *reloc_addr;
+-value = ((Elf32_Addr (*) (void)) value) ();
++value = ((Elf32_Addr (*) (int)) value) (GLRO(dl_hwcap));
+ *reloc_addr = value;
+ break;
+ #endif
diff --git a/meta/recipes-core/eglibc/eglibc_2.18.bb 
b/meta/recipes-core/eglibc/eglibc_2.18.bb
index 17b651f..710b498 100644
--- a/meta/recipes-core/eglibc/eglibc_2.18.bb
+++ b/meta/recipes-core/eglibc/eglibc_2.18.bb
@@ -26,6 +26,7 @@ SRC_URI = 
"http://downloads.yoctoproject.org/releases/eglibc/eglibc-${PV}-svnr23
file://tzselect-awk.patch \

file://0001-eglibc-run-libm-err-tab.pl-with-specific-dirs-in-S.patch \
file://fix-tibetian-locales.patch \
+   file://0001-ARM-Pass-dl_hwcap-to-IFUNC-resolver.patch \
   "
 SRC_URI[md5sum] = "b395b021422a027d89884992e91734fc"
 SRC_URI[sha256sum] = 
"15f564b45dc5dd65faf0875579e3447961ae61e876933384ae05d19328539ad4"
-- 
1.8.4

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-commits] Marko Lindqvist : gtk+: update to upstream version 2.24.20

[Martin Jansa]

On Fri, Aug 23, 2013 at 11:59:53PM +0200, Martin Jansa wrote:
> On Tue, Aug 20, 2013 at 02:21:05PM +, g...@git.openembedded.org wrote:
> > Module: openembedded-core.git
> > Branch: master
> > Commit: 176e5c5bfdeb2529cc40e35870ac49d75439dfeb
> > URL:
> > http://git.openembedded.org/?p=openembedded-core.git&a=commit;h=176e5c5bfdeb2529cc40e35870ac49d75439dfeb
> > 
> > Author: Marko Lindqvist 
> > Date:   Fri Aug 16 11:07:50 2013 +0300
> > 
> > gtk+: update to upstream version 2.24.20
> > 
> > Signed-off-by: Marko Lindqvist 
> > Signed-off-by: Saul Wold 
> 
> I'm not sure if it's caused by this change, but last world build is now
> failing with:
> 
> | Making all in demos
> | make[2]: Entering directory 
> `/home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/armv5te-oe-linux-gnueabi/gtk+/2.24.20-r0/gtk+-2.24.20/demos'
> | 
> /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/bin/gdk-pixbuf-csource
>  --raw --build-list  \
> | apple_red  ./apple-red.png  \
> | gnome_foot ./gnome-foot.png \
> | > test-inline-pixbufs.h \
> | || (rm -f test-inline-pixbufs.h && false)
> | failed to load "./apple-red.png": Couldn't recognize the image file format 
> for file './apple-red.png'
> | make[2]: *** [test-inline-pixbufs.h] Error 1
> | make[2]: Leaving directory 
> `/home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/armv5te-oe-linux-gnueabi/gtk+/2.24.20-r0/gtk+-2.24.20/demos'
> | make[1]: *** [all-recursive] Error 1
> | make[1]: Leaving directory 
> `/home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/armv5te-oe-linux-gnueabi/gtk+/2.24.20-r0/gtk+-2.24.20'
> | make: *** [all] Error 2
> | ERROR: oe_runmake failed
> | WARNING: exit code 1 from a shell command.
> | ERROR: Function failed: do_compile (log file is located at 
> /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/armv5te-oe-linux-gnueabi/gtk+/2.24.20-r0/temp/log.do_compile.26655)
> NOTE: recipe gtk+-2.24.20-r0: task do_compile: Failed
> ERROR: Task 17909 
> (/home/jenkins/oe/shr-core-branches/shr-core/openembedded-core/meta/recipes-gnome/gtk+/gtk+_2.24.20.bb,
>  do_compile) failed with exit code '1'
> 
> IIRC we had these issues with demos before..

I just hit the same issue again.

> > ---
> > 
> >  ...utton-do-not-prelight-in-touchscreen-mode.patch |0
> >  ...Duplicate-the-exec-string-returned-by-gtk.patch |0
> >  .../cellrenderer-cairo.patch   |0
> >  .../configure-nm.patch |0
> >  .../configurefix.patch |0
> >  .../{gtk+-2.24.18 => gtk+-2.24.20}/doc-fixes.patch |0
> >  .../entry-cairo.patch  |0
> >  .../hardcoded_libtool.patch|0
> >  .../{gtk+-2.24.18 => gtk+-2.24.20}/no-demos.patch  |0
> >  .../run-iconcache.patch|0
> >  .../toggle-font.diff   |0
> >  .../{gtk+-2.24.18 => gtk+-2.24.20}/xsettings.patch |0
> >  .../gtk+/{gtk+_2.24.18.bb => gtk+_2.24.20.bb}  |8 +++-
> >  13 files changed, 3 insertions(+), 5 deletions(-)
> > 
> > diff --git 
> > a/meta/recipes-gnome/gtk+/gtk+-2.24.18/0001-GtkButton-do-not-prelight-in-touchscreen-mode.patch
> >  
> > b/meta/recipes-gnome/gtk+/gtk+-2.24.20/0001-GtkButton-do-not-prelight-in-touchscreen-mode.patch
> > similarity index 100%
> > rename from 
> > meta/recipes-gnome/gtk+/gtk+-2.24.18/0001-GtkButton-do-not-prelight-in-touchscreen-mode.patch
> > rename to 
> > meta/recipes-gnome/gtk+/gtk+-2.24.20/0001-GtkButton-do-not-prelight-in-touchscreen-mode.patch
> > diff --git 
> > a/meta/recipes-gnome/gtk+/gtk+-2.24.18/0001-bgo-584832-Duplicate-the-exec-string-returned-by-gtk.patch
> >  
> > b/meta/recipes-gnome/gtk+/gtk+-2.24.20/0001-bgo-584832-Duplicate-the-exec-string-returned-by-gtk.patch
> > similarity index 100%
> > rename from 
> > meta/recipes-gnome/gtk+/gtk+-2.24.18/0001-bgo-584832-Duplicate-the-exec-string-returned-by-gtk.patch
> > rename to 
> > meta/recipes-gnome/gtk+/gtk+-2.24.20/0001-bgo-584832-Duplicate-the-exec-string-returned-by-gtk.patch
> > diff --git a/meta/recipes-gnome/gtk+/gtk+-2.24.18/cellrenderer-cairo.patch 
> > b/meta/recipes-gnome/gtk+/gtk+-2.24.20/cellrenderer-cairo.patch
> > similarity index 100%
> > rename from meta/recipes-gnome/gtk+/gtk+-2.24.18/cellrenderer-cairo.patch
> > rename to meta/recipes-gnome/gtk+/gtk+-2.24.20/cellrenderer-cairo.patch
> > diff --git a/meta/recipes-gnome/gtk+/gtk+-2.24.18/configure-nm.patch 
> > b/meta/recipes-gnome/gtk+/gtk+-2.24.20/configure-nm.patch
> > similarity index 100%
> > rename from meta/recipes-gnome/gtk+/gtk+-2.24.18/configure-nm.patch
> > rename to meta/recipes-gnome/gtk+/gtk+-2.24.20/configure-nm.patch
> > diff --git a/meta/recipes-gnome/gtk+/gtk+-2.24.18/configurefix.patch 
> > b/meta/recipes-gnome/gtk+/gtk+-2.24.20/configurefix.patch
> > similarity index 100%
> > rename

Re: [OE-core] [PATCH] Enable ptest support for lttng.

[Saul Wold]

The usual format for the commit summary is as follows:

lttng: Enable ptest support

Please see the Commit/Patch message guideline for details: 
http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines


Thanks
Sau!

On 09/11/2013 06:09 PM, Stefan Seefeld wrote:

Signed-off-by: Stefan Seefeld 
---
  meta/recipes-kernel/lttng/lttng-tools/run-ptest|  4 ++
  .../recipes-kernel/lttng/lttng-tools/runtest.patch | 52 ++
  meta/recipes-kernel/lttng/lttng-tools_2.3.0.bb |  8 +++-
  3 files changed, 62 insertions(+), 2 deletions(-)
  create mode 100755 meta/recipes-kernel/lttng/lttng-tools/run-ptest
  create mode 100644 meta/recipes-kernel/lttng/lttng-tools/runtest.patch

diff --git a/meta/recipes-kernel/lttng/lttng-tools/run-ptest 
b/meta/recipes-kernel/lttng/lttng-tools/run-ptest
new file mode 100755
index 000..e758815
--- /dev/null
+++ b/meta/recipes-kernel/lttng/lttng-tools/run-ptest
@@ -0,0 +1,4 @@
+#!/bin/sh
+
+make -C tests installcheck
+
diff --git a/meta/recipes-kernel/lttng/lttng-tools/runtest.patch 
b/meta/recipes-kernel/lttng/lttng-tools/runtest.patch
new file mode 100644
index 000..545a5dc
--- /dev/null
+++ b/meta/recipes-kernel/lttng/lttng-tools/runtest.patch
@@ -0,0 +1,52 @@
+diff --git a/Makefile.am b/Makefile.am
+index 584f59b..c2bcabd 100644
+--- a/Makefile.am
 b/Makefile.am
+@@ -12,3 +12,9 @@ dist_doc_DATA = LICENSE \
+ dist_noinst_DATA = CodingStyle
+
+ EXTRA_DIST = extras/lttng-bash_completion gpl-2.0.txt lgpl-2.1.txt
++
++install-ptest:
++  cp -r $(srcdir)/tests $(DESTDIR)
++  for m in $$(find $(DESTDIR)/tests -name Makefile); do \
++  sed -i -e 's|^Makefile:|_Makefile:|' $$m; \
++done
+diff --git a/tests/Makefile.am b/tests/Makefile.am
+index 6d5b00d..3774f9d 100644
+--- a/tests/Makefile.am
 b/tests/Makefile.am
+@@ -1,14 +1,17 @@
+ SUBDIRS = utils regression unit stress
+
+-if USE_PYTHON
+-check-am:
++installcheck-am:
+   ./run.sh unit_tests
+   ./run.sh fast_regression
++if USE_PYTHON
+   ./run.sh with_bindings_regression
+-else
++endif
++
+ check-am:
+   ./run.sh unit_tests
+   ./run.sh fast_regression
++if USE_PYTHON
++  ./run.sh with_bindings_regression
+ endif
+
+ dist_noinst_SCRIPTS = run.sh unit_tests fast_regression long_regression 
root_regression with_bindings_regression
+diff --git a/tests/run.sh b/tests/run.sh
+index c6c50fd..6455359 100755
+--- a/tests/run.sh
 b/tests/run.sh
+@@ -19,4 +19,7 @@
+
+ [ -z "$1" ] && echo "Error: No testlist. Please specify a testlist to run." 
&& exit 1
+
+-prove --merge --exec '' - < $1
++prove --merge -v --exec '' - < $1 | sed \
++  -e 's|^ok \(.*\)|PASS: \1|' \
++  -e 's|^not ok \(.*\)|FAIL: \1|' \
++  | egrep -h 'PASS|FAIL'
diff --git a/meta/recipes-kernel/lttng/lttng-tools_2.3.0.bb 
b/meta/recipes-kernel/lttng/lttng-tools_2.3.0.bb
index 2e0ee15..4322027 100644
--- a/meta/recipes-kernel/lttng/lttng-tools_2.3.0.bb
+++ b/meta/recipes-kernel/lttng/lttng-tools_2.3.0.bb
@@ -10,15 +10,19 @@ LIC_FILES_CHKSUM = 
"file://LICENSE;md5=01d7fc4496aacf37d90df90b90b0cac1 \
  file://lgpl-2.1.txt;md5=0f0d71500e6a57fd24d825f33242b9ca"

  DEPENDS = "liburcu popt lttng-ust"
+RDEPENDS_${PN}-ptest += "make"

  SRCREV = "c9dc1289e040c542f96fbfd558267786816d5703"
  PV = "v2.3.0"

-SRC_URI = "git://git.lttng.org/lttng-tools.git"
+SRC_URI = "git://git.lttng.org/lttng-tools.git \
+   file://runtest.patch \
+   file://run-ptest \
+ "

  S = "${WORKDIR}/git"

-inherit autotools
+inherit autotools ptest

  export KERNELDIR="${STAGING_KERNEL_DIR}"



___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] Enable ptest support for lttng.

[Stefan Seefeld]

On 2013-09-12 13:13, Saul Wold wrote:
> 
> The usual format for the commit summary is as follows:
> 
> lttng: Enable ptest support
> 
> Please see the Commit/Patch message guideline for details:
> http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines

Thanks, I'll follow that guideline for my next patch(es).

Stefan


-- 

  ...ich hab' noch einen Koffer in Berlin...
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 2/5] cdrtools-native: Update from 3.00 to 3.01a17

[Jason Wessel]

The update is needed to support generation of EFI boot images that
work with optical media.  Specifically the "-eltorito-platform efi"
capability for mkisofs is needed.

[YOCTO #4100]

Signed-off-by: Jason Wessel 
---
 .../cdrtools/cdrtools-native_3.00.bb   |   30 ---
 .../cdrtools/cdrtools-native_3.01a17.bb|   31 
 2 files changed, 31 insertions(+), 30 deletions(-)
 delete mode 100644 meta/recipes-devtools/cdrtools/cdrtools-native_3.00.bb
 create mode 100644 meta/recipes-devtools/cdrtools/cdrtools-native_3.01a17.bb

diff --git a/meta/recipes-devtools/cdrtools/cdrtools-native_3.00.bb 
b/meta/recipes-devtools/cdrtools/cdrtools-native_3.00.bb
deleted file mode 100644
index 7e4c381..000
--- a/meta/recipes-devtools/cdrtools/cdrtools-native_3.00.bb
+++ /dev/null
@@ -1,30 +0,0 @@
-# cdrtools-native OE build file
-# Copyright (C) 2004-2006, Advanced Micro Devices, Inc.  All Rights Reserved
-# Released under the MIT license (see packages/COPYING)
-SUMMARY = "A set of tools for CD recording, including cdrecord"
-DESCRIPTION = "A set of tools for CD recording, including cdrecord"
-HOMEPAGE = "http://cdrecord.berlios.de/private/cdrecord.html";
-SECTION = "console/utils"
-LICENSE = "GPLv2"
-LIC_FILES_CHKSUM = "file://COPYING;md5=8d16123ffd39e649a5e4a6bc1de60e6d"
-PR = "r0"
-
-SRC_URI = "ftp://ftp.berlios.de/pub/cdrecord/cdrtools-${PV}.tar.bz2 \
-   file://no_usr_src.patch"
-
-SRC_URI[md5sum] = "f9fbab08fbd458b0d2312976d8c5f558"
-SRC_URI[sha256sum] = 
"7f9cb64820055573b880f77b2f16662a512518336ba95ab49228a1617973423d"
-
-inherit native
-
-STAGE_TEMP = "${WORKDIR}/image-temp"
-
-FILESPATH = "${FILE_DIRNAME}/cdrtools-native/"
-
-do_install() {
-   install -d ${STAGE_TEMP}
-   make install INS_BASE=${STAGE_TEMP}
-
-   install -d ${D}${bindir}/
-   install ${STAGE_TEMP}/bin/* ${D}${bindir}/
-}
diff --git a/meta/recipes-devtools/cdrtools/cdrtools-native_3.01a17.bb 
b/meta/recipes-devtools/cdrtools/cdrtools-native_3.01a17.bb
new file mode 100644
index 000..4a7a160
--- /dev/null
+++ b/meta/recipes-devtools/cdrtools/cdrtools-native_3.01a17.bb
@@ -0,0 +1,31 @@
+# cdrtools-native OE build file
+# Copyright (C) 2004-2006, Advanced Micro Devices, Inc.  All Rights Reserved
+# Released under the MIT license (see packages/COPYING)
+SUMMARY = "A set of tools for CD recording, including cdrecord"
+DESCRIPTION = "A set of tools for CD recording, including cdrecord"
+HOMEPAGE = "http://cdrecord.berlios.de/private/cdrecord.html";
+SECTION = "console/utils"
+LICENSE = "GPLv2 & CDDL-1.0 & LGPLv2.1+"
+LIC_FILES_CHKSUM = "file://COPYING;md5=32f68170be424c2cd64804337726b312"
+PR = "r0"
+
+SRC_URI = "ftp://ftp.berlios.de/pub/cdrecord/alpha/cdrtools-${PV}.tar.bz2";
+
+SRC_URI[md5sum] = "4cef9db0cf15a770c52d65b00bbee2db"
+SRC_URI[sha256sum] = 
"3d613965b213ad83e4be0ba2535e784901839ea4d11a20a2beb6765f0eb76dfa"
+
+S = "${WORKDIR}/cdrtools-3.01"
+
+inherit native
+
+STAGE_TEMP = "${WORKDIR}/image-temp"
+
+FILESPATH = "${FILE_DIRNAME}/cdrtools-native/"
+
+do_install() {
+   install -d ${STAGE_TEMP}
+   make install INS_BASE=${STAGE_TEMP}
+
+   install -d ${D}${bindir}/
+   install ${STAGE_TEMP}/bin/* ${D}${bindir}/
+}
-- 
1.7.9.5

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 5/5] grub-efi.bbclass: Add serial and graphics menu options

[Jason Wessel]

The syslinux.bbclass already has support for automatically generated
serial and graphics menu choices.  This patch adds the same concept to
the grub-efi menu.  That makes it possible to generate a single image
which can boot on a PCBIOS or EFI firmware with consistent looking
boot options.

[YOCTO #4100]

Signed-off-by: Jason Wessel 
---
 meta/classes/grub-efi.bbclass |   41 -
 meta/conf/machine/qemux86-64.conf |2 +-
 meta/conf/machine/qemux86.conf|2 ++
 3 files changed, 30 insertions(+), 15 deletions(-)

diff --git a/meta/classes/grub-efi.bbclass b/meta/classes/grub-efi.bbclass
index c6f5d4e..c07e4a1 100644
--- a/meta/classes/grub-efi.bbclass
+++ b/meta/classes/grub-efi.bbclass
@@ -9,6 +9,7 @@
 # External variables
 # ${INITRD} - indicates a filesystem image to use as an initrd (optional)
 # ${ROOTFS} - indicates a filesystem image to include as the root filesystem 
(optional)
+# ${GRUB_GFXSERIAL} - set this to 1 to have graphics and serial in the boot 
menu
 # ${LABELS} - a list of targets for the automatic config
 # ${APPEND} - an override list of append strings for each label
 # ${GRUB_OPTS} - additional options to add to the config, ';' delimited # 
(optional)
@@ -16,6 +17,7 @@
 
 do_bootimg[depends] += "grub-efi-${TRANSLATED_TARGET_ARCH}-native:do_deploy"
 
+GRUB_SERIAL ?= "console=ttyS0,115200"
 GRUBCFG = "${S}/grub.cfg"
 GRUB_TIMEOUT ?= "10"
 #FIXME: build this from the machine config
@@ -55,6 +57,8 @@ python build_grub_cfg() {
 bb.error("WORKDIR not defined, unable to package")
 return
 
+gfxserial = d.getVar('GRUB_GFXSERIAL', True) or ""
+
 labels = d.getVar('LABELS', True)
 if not labels:
 bb.debug(1, "LABELS not defined, nothing to do")
@@ -88,6 +92,12 @@ python build_grub_cfg() {
 else:
 cfgfile.write('timeout=50\n')
 
+if gfxserial == "1":
+btypes = [ [ " graphics console", "console=tty0" ],
+[ " serial console", d.getVar('GRUB_SERIAL', True) or "" ] ]
+else:
+btypes = [ [ "", "" ] ]
+
 for label in labels.split():
 localdata = d.createCopy()
 
@@ -95,24 +105,27 @@ python build_grub_cfg() {
 if not overrides:
 raise bb.build.FuncFailed('OVERRIDES not defined')
 
-localdata.setVar('OVERRIDES', label + ':' + overrides)
-bb.data.update_data(localdata)
+for btype in btypes:
+localdata.setVar('OVERRIDES', label + ':' + overrides)
+bb.data.update_data(localdata)
 
-cfgfile.write('\nmenuentry \'%s\'{\n' % (label))
-if label == "install":
-label = "install-efi"
-cfgfile.write('linux /vmlinuz LABEL=%s' % (label))
+cfgfile.write('\nmenuentry \'%s%s\'{\n' % (label, btype[0]))
+lb = label
+if label == "install":
+lb = "install-efi"
+cfgfile.write('linux /vmlinuz LABEL=%s' % (lb))
 
-append = localdata.getVar('APPEND', True)
-initrd = localdata.getVar('INITRD', True)
+append = localdata.getVar('APPEND', True)
+initrd = localdata.getVar('INITRD', True)
 
-if append:
-cfgfile.write('%s' % (append))
-cfgfile.write('\n')
+if append:
+cfgfile.write('%s' % (append))
+cfgfile.write(' %s' % btype[1])
+cfgfile.write('\n')
 
-if initrd:
-cfgfile.write('initrd /initrd')
-cfgfile.write('\n}\n')
+if initrd:
+cfgfile.write('initrd /initrd')
+cfgfile.write('\n}\n')
 
 cfgfile.close()
 }
diff --git a/meta/conf/machine/qemux86-64.conf 
b/meta/conf/machine/qemux86-64.conf
index c572225..6f68410 100644
--- a/meta/conf/machine/qemux86-64.conf
+++ b/meta/conf/machine/qemux86-64.conf
@@ -21,6 +21,6 @@ XSERVER = "xserver-xorg \
xf86-input-evdev \
xf86-video-vmware"
 
-MACHINE_FEATURES += "x86"
+MACHINE_FEATURES += "x86 efi"
 
 MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "v86d"
diff --git a/meta/conf/machine/qemux86.conf b/meta/conf/machine/qemux86.conf
index 94ee573..57a9a50 100644
--- a/meta/conf/machine/qemux86.conf
+++ b/meta/conf/machine/qemux86.conf
@@ -22,5 +22,7 @@ XSERVER = "xserver-xorg \
xf86-video-vmware"
 
 MACHINE_FEATURES += "x86"
+MACHINE_FEATURES += "efi"
+#MACHINE_FEATURES += "pcbios"
 
 MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "v86d"
-- 
1.7.9.5

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 4/5] bootimage.bbclass: Improve EFI & PCBIOS+EFI ISO support

[Jason Wessel]

Using the latest mkisofs it is possible to generate 3 different types
of ISO images, which can be used in various scenarios.

1) PCBIOS Only ISO
   - This option remains unchanged by this commit
   - Uses syslinux menus
   - Can be directly copied with dd to a USB device
   - Can be burned to optical media

2) EFI Only ISO
   - Uses grub 2 menus
   - Can be burned to optical media
   - If you want to use this image on a USB device
 extra steps must be taken in order to format the USB
 device with fat32, and copy an EFI loader which will
 in turn load the iso image

3) PCBIOS / EFI ISO
   - This is a hybrid image ISO that will work for case 1 or 2
 as above with the same restrictions and boot menu types
 depending on what type of firmware is installed on
 the hardware or depending on if EFI or "Legacy Boot" is
 enabled on some UEFI firmwares.

[YOCTO #4100]

Signed-off-by: Jason Wessel 
---
 meta/classes/bootimg.bbclass |   37 ++---
 1 file changed, 34 insertions(+), 3 deletions(-)

diff --git a/meta/classes/bootimg.bbclass b/meta/classes/bootimg.bbclass
index 2ed7017..b4301e8 100644
--- a/meta/classes/bootimg.bbclass
+++ b/meta/classes/bootimg.bbclass
@@ -35,6 +35,7 @@ EXCLUDE_FROM_WORLD = "1"
 
 HDDDIR = "${S}/hddimg"
 ISODIR = "${S}/iso"
+EFIIMGDIR = "${S}/efi_img"
 COMPACT_ISODIR = "${S}/iso.z"
 
 BOOTIMG_VOLUME_ID   ?= "boot"
@@ -109,19 +110,49 @@ build_iso() {
mkisofs_opts="-R -z -D -l"
fi
 
-   if [ "${PCBIOS}" = "1" ]; then
+   if [ "${EFI}" = "1" ] ; then
+   # Build a EFI directory to create efi.img
+   mkdir -p ${EFIIMGDIR}/${EFIDIR}
+   cp ${ISODIR}/${EFIDIR}/* ${EFIIMGDIR}${EFIDIR}
+   cp ${ISODIR}/vmlinuz ${EFIIMGDIR}
+   GRUB_IMAGE="bootia32.efi"
+   if [ "${TARGET_ARCH}" = "x86_64" ]; then
+   GRUB_IMAGE="bootx64.efi"
+   fi
+   echo "EFI\\BOOT\\${GRUB_IMAGE}" > ${EFIIMGDIR}/startup.nsh
+   if [ -f "${ISODIR}/initrd" ] ; then
+   cp ${ISODIR}/initrd ${EFIIMGDIR}
+   fi
+   build_fat_img ${EFIIMGDIR} ${ISODIR}/efi.img
+   fi
+
+   # Three ways to build the media
+   if [ "${PCBIOS}" = "1" -a "${EFI}" = "1" ]; then
+   # 1) Build EFI + PCBIOS hybrid
+   mkisofs -A ${BOOTIMG_VOLUME_ID} -V ${BOOTIMG_VOLUME_ID} \
+   -o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso \
+   -b ${ISO_BOOTIMG} -c ${ISO_BOOTCAT} $mkisofs_opts \
+   ${MKISOFS_OPTIONS} \
+   -eltorito-alt-boot -eltorito-platform efi \
+   -b efi.img -no-emul-boot \
+   ${ISODIR}
+   elif [ "${PCBIOS}" = "1" ] ; then
+   # 2) Build PCBIOS only media
mkisofs -V ${BOOTIMG_VOLUME_ID} \
-o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso \
-b ${ISO_BOOTIMG} -c ${ISO_BOOTCAT} $mkisofs_opts \
${MKISOFS_OPTIONS} ${ISODIR}
else
-   bbnote "EFI-only ISO images are untested, please provide 
feedback."
mkisofs -V ${BOOTIMG_VOLUME_ID} \
-o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso \
+   -eltorito-alt-boot -eltorito-platform efi \
+   -b efi.img -no-emul-boot \
-r ${ISODIR}
fi
 
-   isohybrid ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso
+   if [ "${PCBIOS}" = "1" ]; then
+   isohybrid ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso
+   fi
 
cd ${DEPLOY_DIR_IMAGE}
rm -f ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.iso
-- 
1.7.9.5

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 3/5] grub-efi-native: Add support for EFI ISO images

[Jason Wessel]

The iso9660 file system support needs to be added to grub in order to
be able to correctly find the grub.cfg.  The grub commands to locate
the grub.cfg also needs to be encoded into grub's default
configuration.

This change allows the resulting grub binary to work both in the hard
drive / USB boot case or the optical media boot case.

[YOCTO #4100]

Signed-off-by: Jason Wessel 
---
 meta/recipes-bsp/grub/grub-efi-native_2.00.bb |8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-bsp/grub/grub-efi-native_2.00.bb 
b/meta/recipes-bsp/grub/grub-efi-native_2.00.bb
index 2d3d68a..3cff838 100644
--- a/meta/recipes-bsp/grub/grub-efi-native_2.00.bb
+++ b/meta/recipes-bsp/grub/grub-efi-native_2.00.bb
@@ -66,9 +66,13 @@ EXTRA_OECONF = "--with-platform=efi --disable-grub-mkfont \
 --enable-liblzma=no --enable-device-mapper=no 
--enable-libzfs=no"
 
 do_mkimage() {
-   ./grub-mkimage -p /EFI/BOOT -d ./grub-core/ \
+   # Search for the grub.cfg on the local boot media with built in config 
file
+   echo 'search.file /EFI/BOOT/grub.cfg root' > cfg
+   echo 'set prefix=($root)/EFI/BOOT' >> cfg
+
+   ./grub-mkimage -c cfg -p /EFI/BOOT -d ./grub-core/ \
   -O ${GRUB_TARGET}-efi -o ./${GRUB_IMAGE} \
-  boot linux ext2 fat serial part_msdos part_gpt normal 
efi_gop
+  boot linux ext2 fat serial part_msdos part_gpt normal 
efi_gop iso9660 search
 }
 addtask mkimage after do_compile before do_install
 
-- 
1.7.9.5

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 0/5] Improved EFI boot support

[Jason Wessel]

The goal of this patch set is to put the EFI ISO boot method on par
with the ISO PCBIOS boot method.  This also allows for the creation of
a single ISO image which can boot in "legacy boot" mode or EFI boot
mode.

In order to make this possible the cdrtools needed an update to the
very latest and this brings in an license change.  Given that change
it was not entirely clear to me if we needed to leave the older
package around.  I opted to remove the older package recipe since
there was no clean way to fail in the case you wanted to build EFI
boot media.

The bbnote that was previously in the bootimg.bbclass about EFI only
media being untested was a bit of an understatement, as the images
would not even build without errors due to the call to isohybrid.  I
removed any such warnings because that path has been fully vetted now.

Cheers,
Jason.



Jason Wessel (5):
  bootimage.bbclass: Move fat image creation into a function
  cdrtools-native: Update from 3.00 to 3.01a17
  grub-efi-native: Add support for EFI ISO images
  bootimage.bbclass: Improve EFI & PCBIOS+EFI ISO support
  grub-efi.bbclass: Add serial and graphics menu options

 meta/classes/bootimg.bbclass   |  147 
 meta/classes/grub-efi.bbclass  |   41 --
 meta/conf/machine/qemux86-64.conf  |2 +-
 meta/conf/machine/qemux86.conf |2 +
 meta/recipes-bsp/grub/grub-efi-native_2.00.bb  |8 +-
 ...s-native_3.00.bb => cdrtools-native_3.01a17.bb} |   13 +-
 6 files changed, 135 insertions(+), 78 deletions(-)
 rename meta/recipes-devtools/cdrtools/{cdrtools-native_3.00.bb => 
cdrtools-native_3.01a17.bb} (64%)
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v4] libtool: fix resolve of lt_sysroot

[Hans Beckerus]

On 2013-09-12 11:09, Hans Beckerus wrote:

On 2013-09-12 8:02, Hans Beckérus wrote:

On Thu, Sep 12, 2013 at 7:09 PM, Saul Wold  wrote:

On 09/11/2013 09:05 AM, Hans Beckérus wrote:
On Wed, Sep 11, 2013 at 10:15 AM, Hans Beckérus 


wrote:
On Tue, Sep 10, 2013 at 11:33 PM, Saul Wold  
wrote:

On 09/10/2013 07:56 AM, hans.becke...@gmail.com wrote:


From: Hans Beckerus 

This patch updates libtool.m4 (and its output) to resolve a problem
with variable 'lt_sysroot' not being properly updated if the option
'--with[-libtool]-sysroot' is not provided when running the 
'configure'

script for a package.

According to the help text ouput from 'configure':
--with-libtool-sysroot=DIR Search for dependent libraries within 
DIR
  (or the compiler's sysrooot if not 
specified).


Due to swapped cases in a switch statement, when checking if the 
option

was specified or not, wrong actions were taken resulting in an
incorrect sysroot and failures to properly locate e.g. .la files.


What kind of testing have you done with this?  Have you tried a full
world
build?  This kind of change scares me a little as what issues we 
might

have
patched around or behavior built into software.


In the area of testing, it has been verified in my local environment,
which covers a few different ARM based images and SDK installs. I 
have

not done a build of all possible packages in my Yocto branch.

I just completed a world build locally and have failures in 
file-native
guile-native, and gtk+3, not sure if we need to invalidate 
sstate, I am

starting a clean build.


I have no issues with neither of those packages, at least not in
stand-alone builds.
Can you specify a little more exactly what goes wrong during the 
build

stage?


Actually, someone else here hit a couple of packages that had  SDK
build failures after applying the patch.
In this case it was gettext-native and gnutls-native. After doing a
'cleanall' of those packages rebuild went fine.
So, yes, sstate should probably be invalidated after a change like
this since some packages does not seem to be rebuilt properly
otherwise. Are they missing a DEPEND to libtool maybe?

No, these are from a clean build space with no sstate either, I 
wanted to

verify that.

Also, anything that inherits autotools automagically gets a libtool
dependency added, so we should not be adding that kind of dependency in
recipes.

I have attached the 3 failures I saw for a completely clean build, note
these are native tools: file-native, guile-native and apr-util-native.


Again, I have no issues what so ever to build these packages one by
one after a clean sstate.
On the other hand, I am on a poky 1.4 baseline. I need to bring in the
latest oe-core and build world from there.
I have now tried a world build on oe-core master/latest and I can 
confirm that also I get build errors on a clean build root.
I only went as far as stopping at file-native. I think I need to debug 
this problem package by package. Something is definitely spooky here.
On poky 1.4 it works like a charm, on current oe-core it does not. 
Also, doing a clean sstate or building "file-native" separately
makes no difference.  What I discovered is that the sysroot is 
completely wrong. It has been resolved to "/" which means the wrong
set of libraries are picked up. If I patched the generated 
x86_64-linux-libtool and replaced lt_sysroot with the actual sysroot 
in use
compilation went fine! The libtool patch *is* good. No question about 
that. It is an obvious bug that has been corrected. To me this looks like

some kind of  a double-fault! I need to dig deeper.


I now got a somewhat better picture of what is going on. I know what is 
failing, and why. But currently I have no solution ready. Actually there 
are some nasty traps to get caught in here :(. The problem is actually 
as simple as it is obvious. For all those native packages that do work 
(this is a unique problem for native packages using libtool), they all 
seem to share a common thing in their recipes:


EXTRA_OECONF += " --with-libtool-sysroot=${STAGING_DIR_NATIVE}"

Great! This is the way to do it. But, what if someone forgets to do 
this? Well the answer is; it will most likely *not* compile!
Since libtool now has been fixed to correctly pick up the sysroot from 
the compiler (using --print-sysroot) if --with-libtool-sysroot is not 
specified it will try to execute ${CC} --print-sysroot. Bummer! ${CC} is 
most likely simply set to 'gcc' for native packages. That is, the local 
host compiler is used.
The sysroot for that is of course "/". And it should be. Otherwise it 
will bring in the wrong set of header files and libraries. But, there is 
another problem here. We should not let libtool use "/"! Because even if 
we use the local host compiler for native packages, we still use the 
oe-core upstream version of libtool, and that does not like using "/" as 
sysroot.  If it does everything becomes a mess. And that is exactly what 
seems to hap

Re: [OE-core] [PATCH 2/5] cdrtools-native: Update from 3.00 to 3.01a17

[Saul Wold]

On 09/12/2013 10:19 AM, Jason Wessel wrote:

The update is needed to support generation of EFI boot images that
work with optical media.  Specifically the "-eltorito-platform efi"
capability for mkisofs is needed.

[YOCTO #4100]

Signed-off-by: Jason Wessel 
---
  .../cdrtools/cdrtools-native_3.00.bb   |   30 ---
  .../cdrtools/cdrtools-native_3.01a17.bb|   31 
  2 files changed, 31 insertions(+), 30 deletions(-)
  delete mode 100644 meta/recipes-devtools/cdrtools/cdrtools-native_3.00.bb
  create mode 100644 meta/recipes-devtools/cdrtools/cdrtools-native_3.01a17.bb

diff --git a/meta/recipes-devtools/cdrtools/cdrtools-native_3.00.bb 
b/meta/recipes-devtools/cdrtools/cdrtools-native_3.00.bb
deleted file mode 100644
index 7e4c381..000
--- a/meta/recipes-devtools/cdrtools/cdrtools-native_3.00.bb
+++ /dev/null
@@ -1,30 +0,0 @@
-# cdrtools-native OE build file
-# Copyright (C) 2004-2006, Advanced Micro Devices, Inc.  All Rights Reserved
-# Released under the MIT license (see packages/COPYING)
-SUMMARY = "A set of tools for CD recording, including cdrecord"
-DESCRIPTION = "A set of tools for CD recording, including cdrecord"
-HOMEPAGE = "http://cdrecord.berlios.de/private/cdrecord.html";
-SECTION = "console/utils"
-LICENSE = "GPLv2"
-LIC_FILES_CHKSUM = "file://COPYING;md5=8d16123ffd39e649a5e4a6bc1de60e6d"
-PR = "r0"
-
-SRC_URI = "ftp://ftp.berlios.de/pub/cdrecord/cdrtools-${PV}.tar.bz2 \
-   file://no_usr_src.patch"
-
-SRC_URI[md5sum] = "f9fbab08fbd458b0d2312976d8c5f558"
-SRC_URI[sha256sum] = 
"7f9cb64820055573b880f77b2f16662a512518336ba95ab49228a1617973423d"
-
-inherit native
-
-STAGE_TEMP = "${WORKDIR}/image-temp"
-
-FILESPATH = "${FILE_DIRNAME}/cdrtools-native/"
-
-do_install() {
-   install -d ${STAGE_TEMP}
-   make install INS_BASE=${STAGE_TEMP}
-
-   install -d ${D}${bindir}/
-   install ${STAGE_TEMP}/bin/* ${D}${bindir}/
-}
diff --git a/meta/recipes-devtools/cdrtools/cdrtools-native_3.01a17.bb 
b/meta/recipes-devtools/cdrtools/cdrtools-native_3.01a17.bb
new file mode 100644
index 000..4a7a160
--- /dev/null
+++ b/meta/recipes-devtools/cdrtools/cdrtools-native_3.01a17.bb
@@ -0,0 +1,31 @@
+# cdrtools-native OE build file
+# Copyright (C) 2004-2006, Advanced Micro Devices, Inc.  All Rights Reserved
+# Released under the MIT license (see packages/COPYING)
+SUMMARY = "A set of tools for CD recording, including cdrecord"
+DESCRIPTION = "A set of tools for CD recording, including cdrecord"
+HOMEPAGE = "http://cdrecord.berlios.de/private/cdrecord.html";
+SECTION = "console/utils"
+LICENSE = "GPLv2 & CDDL-1.0 & LGPLv2.1+"
+LIC_FILES_CHKSUM = "file://COPYING;md5=32f68170be424c2cd64804337726b312"
+PR = "r0"

You can drop the PR completely.


+
+SRC_URI = "ftp://ftp.berlios.de/pub/cdrecord/alpha/cdrtools-${PV}.tar.bz2";
+
+SRC_URI[md5sum] = "4cef9db0cf15a770c52d65b00bbee2db"
+SRC_URI[sha256sum] = 
"3d613965b213ad83e4be0ba2535e784901839ea4d11a20a2beb6765f0eb76dfa"
+
+S = "${WORKDIR}/cdrtools-3.01"
+
+inherit native
+
+STAGE_TEMP = "${WORKDIR}/image-temp"
+
+FILESPATH = "${FILE_DIRNAME}/cdrtools-native/"
+
+do_install() {
+   install -d ${STAGE_TEMP}
+   make install INS_BASE=${STAGE_TEMP}
+
+   install -d ${D}${bindir}/
+   install ${STAGE_TEMP}/bin/* ${D}${bindir}/
+}

I was working on this update also and was able to simplify this 
do_install to the following:


EXTRA_OEMAKE += "GMAKE_NOWARN=true INS_BASE=${prefix_native} DESTDIR=${D}

do_install() {
oe_runmake install
}

This allowed me to get rid of the STAGE_TEMP

Sau!

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] Enable ptest support for lttng.

[Christian Babeux]

> Still, I think it's good to include these tests. If anything they may
> just provide more motivation to address the underlying issue. :-)

Absolutely! I'll start a thread on lttng-dev to see how we can deal
with the current testsuite limitations.

>>> ++prove --merge -v --exec '' - < $1 | sed \
>>> ++  -e 's|^ok \(.*\)|PASS: \1|' \
>>> ++  -e 's|^not ok \(.*\)|FAIL: \1|' \
>>> ++  | egrep -h 'PASS|FAIL'
>> This is sadly needed because we are using TAP as our standardized test
>> output format across the multiples lttng codebases.
>
> Do you think it would be worthwhile submitting this patch upstream ?

This is pretty much OpenEmbedded specific and I don't think it is of
much use outside of ptest support.

> (The output format of prove is not the easiest to understand, and even
> with the above some information may be lost. A more robust fix would
> probably include a dedicated TAP formatter plugin
> (http://perldoc.perl.org/TAP/Formatter/Console.html) that produces
> ptest-compatible output.

Yes that would be a cleaner way of dealing with it. We would only need
to feed the appropriate 'testlist' file to this script and get proper
conversion of TAP to Automake-style test output. I'm wondering if such
a script would be useful for other projects/recipes using TAP tests
within oe/yocto?

Thanks,

Christian Babeux
EfficiOS Inc.
http://www.efficios.com
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] scripts/contrib/build-perf-test.sh: record size in kb and remove extra spaces

[Stefan Stanacar]

Signed-off-by: Stefan Stanacar 
---
 scripts/contrib/build-perf-test.sh | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/scripts/contrib/build-perf-test.sh 
b/scripts/contrib/build-perf-test.sh
index ce0fb9a..be3b648 100755
--- a/scripts/contrib/build-perf-test.sh
+++ b/scripts/contrib/build-perf-test.sh
@@ -170,6 +170,7 @@ fi
 # Disabling the network sanity check helps a bit (because of my crappy network 
connection and/or proxy)
 echo "CONNECTIVITY_CHECK_URIS =\"\"" >> conf/local.conf
 
+
 #
 # Functions
 #
@@ -284,7 +285,7 @@ test1_p1 () {
 do_rmsstate
 do_sync
 bbtime $IMAGE
-s=`du -sh tmp | sed 's/tmp//'`
+s=`du -s tmp | sed 's/tmp//' | sed 's/[ \t]*$//'`
 SIZES[(( size_count++ ))]="$s"
 log "SIZE of tmp dir is: $s"
 log "Buildstats are saved in $OUTDIR/buildstats-test1"
@@ -307,7 +308,7 @@ test1_p3 () {
 do_sync
 bbtime $IMAGE
 sed -i 's/INHERIT += \"rm_work\"//' conf/local.conf
-s=`du -sh tmp | sed 's/tmp//'`
+s=`du -s tmp | sed 's/tmp//' | sed 's/[ \t]*$//'`
 SIZES[(( size_count++ ))]="$s"
 log "SIZE of tmp dir is: $s"
 log "Buildstats are saved in $OUTDIR/buildstats-test13"
-- 
1.8.3.1

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/5] cdrtools-native: Update from 3.00 to 3.01a17

[Darren Hart]

On Thu, 2013-09-12 at 12:19 -0500, Jason Wessel wrote:
> The update is needed to support generation of EFI boot images that
> work with optical media.  Specifically the "-eltorito-platform efi"
> capability for mkisofs is needed.
> 
> [YOCTO #4100]
> 
> Signed-off-by: Jason Wessel 
> ---
>  .../cdrtools/cdrtools-native_3.00.bb   |   30 ---
>  .../cdrtools/cdrtools-native_3.01a17.bb|   31 
> 
>  2 files changed, 31 insertions(+), 30 deletions(-)
>  delete mode 100644 meta/recipes-devtools/cdrtools/cdrtools-native_3.00.bb
>  create mode 100644 meta/recipes-devtools/cdrtools/cdrtools-native_3.01a17.bb
> 

...

> diff --git a/meta/recipes-devtools/cdrtools/cdrtools-native_3.01a17.bb 
> b/meta/recipes-devtools/cdrtools/cdrtools-native_3.01a17.bb
> new file mode 100644
> index 000..4a7a160
> --- /dev/null
> +++ b/meta/recipes-devtools/cdrtools/cdrtools-native_3.01a17.bb
> @@ -0,0 +1,31 @@
> +# cdrtools-native OE build file
> +# Copyright (C) 2004-2006, Advanced Micro Devices, Inc.  All Rights Reserved
> +# Released under the MIT license (see packages/COPYING)
> +SUMMARY = "A set of tools for CD recording, including cdrecord"
> +DESCRIPTION = "A set of tools for CD recording, including cdrecord"
> +HOMEPAGE = "http://cdrecord.berlios.de/private/cdrecord.html";
> +SECTION = "console/utils"
> +LICENSE = "GPLv2 & CDDL-1.0 & LGPLv2.1+"
> +LIC_FILES_CHKSUM = "file://COPYING;md5=32f68170be424c2cd64804337726b312"
> +PR = "r0"

Recent consensus is that we drop the PR, especially if set to "r0".
Otherwise, looks good.

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v4] libtool: fix resolve of lt_sysroot

[Saul Wold]

On 09/12/2013 02:09 PM, Hans Beckerus wrote:

On 2013-09-12 8:02, Hans Beckérus wrote:

On Thu, Sep 12, 2013 at 7:09 PM, Saul Wold  wrote:

On 09/11/2013 09:05 AM, Hans Beckérus wrote:

On Wed, Sep 11, 2013 at 10:15 AM, Hans Beckérus

wrote:

On Tue, Sep 10, 2013 at 11:33 PM, Saul Wold 
wrote:

On 09/10/2013 07:56 AM, hans.becke...@gmail.com wrote:


From: Hans Beckerus 

This patch updates libtool.m4 (and its output) to resolve a problem
with variable 'lt_sysroot' not being properly updated if the option
'--with[-libtool]-sysroot' is not provided when running the
'configure'
script for a package.

According to the help text ouput from 'configure':
--with-libtool-sysroot=DIR Search for dependent libraries within DIR
  (or the compiler's sysrooot if not
specified).

Due to swapped cases in a switch statement, when checking if the
option
was specified or not, wrong actions were taken resulting in an
incorrect sysroot and failures to properly locate e.g. .la files.


What kind of testing have you done with this?  Have you tried a full
world
build?  This kind of change scares me a little as what issues we
might
have
patched around or behavior built into software.


In the area of testing, it has been verified in my local environment,
which covers a few different ARM based images and SDK installs. I have
not done a build of all possible packages in my Yocto branch.


I just completed a world build locally and have failures in
file-native
guile-native, and gtk+3, not sure if we need to invalidate sstate,
I am
starting a clean build.


I have no issues with neither of those packages, at least not in
stand-alone builds.
Can you specify a little more exactly what goes wrong during the build
stage?


Actually, someone else here hit a couple of packages that had  SDK
build failures after applying the patch.
In this case it was gettext-native and gnutls-native. After doing a
'cleanall' of those packages rebuild went fine.
So, yes, sstate should probably be invalidated after a change like
this since some packages does not seem to be rebuilt properly
otherwise. Are they missing a DEPEND to libtool maybe?


No, these are from a clean build space with no sstate either, I
wanted to
verify that.

Also, anything that inherits autotools automagically gets a libtool
dependency added, so we should not be adding that kind of dependency in
recipes.

I have attached the 3 failures I saw for a completely clean build, note
these are native tools: file-native, guile-native and apr-util-native.


Again, I have no issues what so ever to build these packages one by
one after a clean sstate.
On the other hand, I am on a poky 1.4 baseline. I need to bring in the
latest oe-core and build world from there.

I have now tried a world build on oe-core master/latest and I can
confirm that also I get build errors on a clean build root.
I only went as far as stopping at file-native. I think I need to debug
this problem package by package. Something is definitely spooky here.


Spooky is the right word for it, I was not sure what was going on and do 
not have the time to spend on it right now, that's why I kicked it back 
your way.



On poky 1.4 it works like a charm, on current oe-core it does not. Also,
doing a clean sstate or building "file-native" separately
makes no difference.  What I discovered is that the sysroot is
completely wrong. It has been resolved to "/" which means the wrong
set of libraries are picked up. If I patched the generated
x86_64-linux-libtool and replaced lt_sysroot with the actual sysroot in use
compilation went fine! The libtool patch *is* good. No question about
Right, I understand that, it's just the behavior has now changed and 
other things may have relied on the broken behavior.



that. It is an obvious bug that has been corrected. To me this looks like
some kind of  a double-fault! I need to dig deeper.

I was kind of wondering if somehow some of those upstreams worked around 
the problem in libtool and now that you fixed it, there is strange breakage.


Thanks for confirming the issue and digging into it, these fixes might 
have to go upstream also.


Sau!



Thanks.
Hans


Hans


Sau!



Thanks,
Hans


I have not dug too deeply into this yet.

Sau!





For current upstream status see:
http://lists.gnu.org/archive/html/bug-libtool/2013-09/msg5.html

Signed-off-by: Hans Beckerus 
---
meta/recipes-devtools/libtool/libtool-2.4.2.inc|  1 +
.../libtool/libtool/fix-resolve-lt-sysroot.patch   | 35
++
2 files changed, 36 insertions(+)
create mode 100644
meta/recipes-devtools/libtool/libtool/fix-resolve-lt-sysroot.patch

diff --git a/meta/recipes-devtools/libtool/libtool-2.4.2.inc
b/meta/recipes-devtools/libtool/libtool-2.4.2.inc
index bb4ddf0..92e4949 100644
--- a/meta/recipes-devtools/libtool/libtool-2.4.2.inc
+++ b/meta/recipes-devtools/libtool/libtool-2.4.2.inc
@@ -20,6 +20,7 @@ SRC_URI =
"${GNU_MIRROR}/libtool/libtool-${PV}.tar.gz
\

Re: [OE-core] [PATCH] Enable ptest support for lttng.

[Christian Babeux]

Hi Stefan,

> +
> +make -C tests installcheck
> +

A majority of the tests will probably fail this way. As of now, most
tests assumes that they are being runned in the build tree and expect
binaries to be at specific paths. We will have to fix this upstream if
you want to integrate our testsuite with ptest.

> ++prove --merge -v --exec '' - < $1 | sed \
> ++  -e 's|^ok \(.*\)|PASS: \1|' \
> ++  -e 's|^not ok \(.*\)|FAIL: \1|' \
> ++  | egrep -h 'PASS|FAIL'

This is sadly needed because we are using TAP as our standardized test
output format across the multiples lttng codebases.

Thanks,

Christian Babeux
EfficiOS Inc.
http://www.efficios.com
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/5] bootimage.bbclass: Move fat image creation into a function

[Darren Hart]

On Thu, 2013-09-12 at 12:19 -0500, Jason Wessel wrote:
> In order to call the fat image creation multiple times it needs to be
> in its own function.  A future commit will make use of the new
> function to additionally create EFI image files for use with an ISO.
> 
> [YOCTO #4100]
> 
> Signed-off-by: Jason Wessel 

Thanks Jason!

Also, see https://bugzilla.yoctoproject.org/show_bug.cgi?id=1913. I
think you can add [YOCTO #1913] to your commit message. This isn't in a
new bbclass, but I think that's fine. The abstraction was the important
thing.

Acked-by: Darren Hart 


> ---
>  meta/classes/bootimg.bbclass |  110 
> ++
>  1 file changed, 58 insertions(+), 52 deletions(-)
> 
> diff --git a/meta/classes/bootimg.bbclass b/meta/classes/bootimg.bbclass
> index b312e0d..2ed7017 100644
> --- a/meta/classes/bootimg.bbclass
> +++ b/meta/classes/bootimg.bbclass
> @@ -128,6 +128,63 @@ build_iso() {
>   ln -s ${IMAGE_NAME}.iso ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.iso
>  }
>  
> +build_fat_img() {
> + FATSOURCEDIR=$1
> + FATIMG=$2
> +
> + # Calculate the size required for the final image including the
> + # data and filesystem overhead.
> + # Sectors: 512 bytes
> + #  Blocks: 1024 bytes
> +
> + # Determine the sector count just for the data
> + SECTORS=$(expr $(du --apparent-size -ks ${FATSOURCEDIR} | cut -f 1) \* 
> 2)
> +
> + # Account for the filesystem overhead. This includes directory
> + # entries in the clusters as well as the FAT itself.
> + # Assumptions:
> + #   FAT32 (12 or 16 may be selected by mkdosfs, but the extra
> + #   padding will be minimal on those smaller images and not
> + #   worth the logic here to caclulate the smaller FAT sizes)
> + #   < 16 entries per directory
> + #   8.3 filenames only
> +
> + # 32 bytes per dir entry
> + DIR_BYTES=$(expr $(find ${FATSOURCEDIR} | tail -n +2 | wc -l) \* 32)
> + # 32 bytes for every end-of-directory dir entry
> + DIR_BYTES=$(expr $DIR_BYTES + $(expr $(find ${FATSOURCEDIR} -type d | 
> tail -n +2 | wc -l) \* 32))
> + # 4 bytes per FAT entry per sector of data
> + FAT_BYTES=$(expr $SECTORS \* 4)
> + # 4 bytes per FAT entry per end-of-cluster list
> + FAT_BYTES=$(expr $FAT_BYTES + $(expr $(find ${FATSOURCEDIR} -type d | 
> tail -n +2 | wc -l) \* 4))
> +
> + # Use a ceiling function to determine FS overhead in sectors
> + DIR_SECTORS=$(expr $(expr $DIR_BYTES + 511) / 512)
> + # There are two FATs on the image
> + FAT_SECTORS=$(expr $(expr $(expr $FAT_BYTES + 511) / 512) \* 2)
> + SECTORS=$(expr $SECTORS + $(expr $DIR_SECTORS + $FAT_SECTORS))
> +
> + # Determine the final size in blocks accounting for some padding
> + BLOCKS=$(expr $(expr $SECTORS / 2) + ${BOOTIMG_EXTRA_SPACE})
> +
> + # Ensure total sectors is an integral number of sectors per
> + # track or mcopy will complain. Sectors are 512 bytes, and we
> + # generate images with 32 sectors per track. This calculation is
> + # done in blocks, thus the mod by 16 instead of 32.
> + BLOCKS=$(expr $BLOCKS + $(expr 16 - $(expr $BLOCKS % 16)))
> +
> + # mkdosfs will sometimes use FAT16 when it is not appropriate,
> + # resulting in a boot failure from SYSLINUX. Use FAT32 for
> + # images larger than 512MB, otherwise let mkdosfs decide.
> + if [ $(expr $BLOCKS / 1024) -gt 512 ]; then
> + FATSIZE="-F 32"
> + fi
> +
> + mkdosfs ${FATSIZE} -n ${BOOTIMG_VOLUME_ID} -S 512 -C ${FATIMG} ${BLOCKS}
> + # Copy FATSOURCEDIR recursively into the image file directly
> + mcopy -i ${FATIMG} -s ${FATSOURCEDIR}/* ::/
> +}
> +
>  build_hddimg() {
>   # Create an HDD image
>   if [ "${NOHDD}" != "1" ] ; then
> @@ -140,58 +197,7 @@ build_hddimg() {
>   grubefi_hddimg_populate
>   fi
>  
> - # Calculate the size required for the final image including the
> - # data and filesystem overhead.
> - # Sectors: 512 bytes
> - #  Blocks: 1024 bytes
> -
> - # Determine the sector count just for the data
> - SECTORS=$(expr $(du --apparent-size -ks ${HDDDIR} | cut -f 1) 
> \* 2)
> -
> - # Account for the filesystem overhead. This includes directory
> - # entries in the clusters as well as the FAT itself.
> - # Assumptions:
> - #   FAT32 (12 or 16 may be selected by mkdosfs, but the extra
> - #   padding will be minimal on those smaller images and not
> - #   worth the logic here to caclulate the smaller FAT sizes)
> - #   < 16 entries per directory
> - #   8.3 filenames only
> -
> - # 32 bytes per dir entry
> - DIR_BYTES=$(expr $(find ${HDDDIR} | tail -n +2 | wc -l) \* 32)
> - # 32 bytes for every end-of-directory dir entry
> - DIR_BYTES=$(expr $DIR_BYTES + $(expr

Re: [OE-core] [PATCH] boot-directdisk: Allow for EFI-only boot direct disk images

[Darren Hart]

On Thu, 2013-09-12 at 16:02 -0300, Joao Henrique Ferreira de Freitas
wrote:
> From: João Henrique Ferreira de Freitas 
> 
> Condition building PCBIOS legacy images on MACHINE_FEATURES containing 
> "pcbios"
> or not containing "efi". This ensures existing BSPs will continue to get 
> the
> old PCBIOS legacy-only images. New BSPs can add "efi", "pcbios", or both. 
> The
> images created likewise support one or the other or both.

Nitpic: please keep your commit message line length under something like
72 chars to allow for some indentation from the git log command,
otherwise this gets truncated in an 80 char terminal.

Otherwise looks good.

> 
> Signed-off-by: João Henrique Ferreira de Freitas 

Reviewed-by: Darren Hart 

> ---
>  meta/classes/boot-directdisk.bbclass | 65 
> ++--
>  meta/classes/syslinux.bbclass|  5 +++
>  2 files changed, 60 insertions(+), 10 deletions(-)
> 
> diff --git a/meta/classes/boot-directdisk.bbclass 
> b/meta/classes/boot-directdisk.bbclass
> index 8a55aae..4b9d7bd 100644
> --- a/meta/classes/boot-directdisk.bbclass
> +++ b/meta/classes/boot-directdisk.bbclass
> @@ -31,6 +31,29 @@ EXCLUDE_FROM_WORLD = "1"
>  BOOTDD_VOLUME_ID   ?= "boot"
>  BOOTDD_EXTRA_SPACE ?= "16384"
>  
> +EFI = "${@base_contains("MACHINE_FEATURES", "efi", "1", "0", d)}"
> +EFI_CLASS = "${@base_contains("MACHINE_FEATURES", "efi", "grub-efi", "", d)}"
> +
> +# Include legacy boot if MACHINE_FEATURES includes "pcbios" or if it does not
> +# contain "efi". This way legacy is supported by default if neither is
> +# specified, maintaining the original behavior.
> +def pcbios(d):
> +pcbios = base_contains("MACHINE_FEATURES", "pcbios", "1", "0", d)
> +if pcbios == "0":
> +pcbios = base_contains("MACHINE_FEATURES", "efi", "0", "1", d)
> +return pcbios
> +
> +def pcbios_class(d):
> +if d.getVar("PCBIOS", True) == "1":
> +return "syslinux"
> +return ""
> +
> +PCBIOS = "${@pcbios(d)}"
> +PCBIOS_CLASS = "${@pcbios_class(d)}"
> +
> +inherit ${PCBIOS_CLASS}
> +inherit ${EFI_CLASS}
> +
>  # Get the build_syslinux_cfg() function from the syslinux class
>  
>  AUTO_SYSLINUXCFG = "1"
> @@ -38,17 +61,32 @@ DISK_SIGNATURE ?= "${DISK_SIGNATURE_GENERATED}"
>  SYSLINUX_ROOT ?= "root=/dev/sda2"
>  SYSLINUX_TIMEOUT ?= "10"
>  
> -inherit syslinux
> - 
> +populate() {
> + DEST=$1
> + install -d ${DEST}
> +
> + # Install bzImage, initrd, and rootfs.img in DEST for all loaders to 
> use.
> + install -m 0644 ${STAGING_KERNEL_DIR}/bzImage ${DEST}/vmlinuz
> +
> + if [ -n "${INITRD}" ] && [ -s "${INITRD}" ]; then
> + install -m 0644 ${INITRD} ${DEST}/initrd
> + fi
> +
> +}
> +
>  build_boot_dd() {
>   HDDDIR="${S}/hdd/boot"
>   HDDIMG="${S}/hdd.image"
>   IMAGE=${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.hdddirect
>  
> - install -d $HDDDIR
> - install -m 0644 ${STAGING_KERNEL_DIR}/bzImage $HDDDIR/vmlinuz
> - install -m 0644 ${S}/syslinux.cfg $HDDDIR/syslinux.cfg
> - install -m 444 ${STAGING_DATADIR}/syslinux/ldlinux.sys 
> $HDDDIR/ldlinux.sys
> + populate ${HDDDIR}
> +
> + if [ "${PCBIOS}" = "1" ]; then
> + syslinux_hddimg_populate
> + fi
> + if [ "${EFI}" = "1" ]; then
> + grubefi_hddimg_populate
> + fi
>  
>   BLOCKS=`du -bks $HDDDIR | cut -f 1`
>   BLOCKS=`expr $BLOCKS + ${BOOTDD_EXTRA_SPACE}`
> @@ -62,7 +100,9 @@ build_boot_dd() {
>   mkdosfs -n ${BOOTDD_VOLUME_ID} -S 512 -C $HDDIMG $BLOCKS 
>   mcopy -i $HDDIMG -s $HDDDIR/* ::/
>  
> - syslinux $HDDIMG
> + if [ "${PCBIOS}" = "1" ]; then
> + syslinux_hdddirect_install $HDDIMG
> + fi  
>   chmod 644 $HDDIMG
>  
>   ROOTFSBLOCKS=`du -Lbks ${ROOTFS} | cut -f 1`
> @@ -85,9 +125,11 @@ build_boot_dd() {
>   dd of=$IMAGE bs=1 seek=440 conv=notrunc
>  
>   OFFSET=`expr $END2 / 512`
> - dd if=${STAGING_DATADIR}/syslinux/mbr.bin of=$IMAGE conv=notrunc
> + if [ "${PCBIOS}" = "1" ]; then
> + dd if=${STAGING_DATADIR}/syslinux/mbr.bin of=$IMAGE conv=notrunc
> + fi
>   dd if=$HDDIMG of=$IMAGE conv=notrunc seek=1 bs=512
> - dd if=${ROOTFS} of=$IMAGE conv=notrunc seek=$OFFSET bs=512
> + dd if=${ROOTFS} of=$IMAGE conv=notrunc seek=$OFFSET bs=512  
>  
>   cd ${DEPLOY_DIR_IMAGE}
>   rm -f ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.hdddirect
> @@ -96,7 +138,10 @@ build_boot_dd() {
>  
>  python do_bootdirectdisk() {
>  validate_disk_signature(d)
> -bb.build.exec_func('build_syslinux_cfg', d)
> +if d.getVar("PCBIOS", True) == "1":
> +bb.build.exec_func('build_syslinux_cfg', d)
> +if d.getVar("EFI", True) == "1":
> +bb.build.exec_func('build_grub_cfg', d)
>  bb.build.exec_func('build_boot_dd', d)
>  }
>  
> diff --git a/meta/classes/syslinux.bbclass b/meta/classes/syslinux.bbclass
> index 501bc6d..dae6609 100644
> --- a/meta/classes/syslinux.bbclass
> +++ b/meta/c

[OE-core] [PATCH] boot-directdisk: Allow for EFI-only boot direct disk images

[Joao Henrique Ferreira de Freitas]

From: João Henrique Ferreira de Freitas 

Condition building PCBIOS legacy images on MACHINE_FEATURES containing 
"pcbios"
or not containing "efi". This ensures existing BSPs will continue to get the
old PCBIOS legacy-only images. New BSPs can add "efi", "pcbios", or both. 
The
images created likewise support one or the other or both.

Signed-off-by: João Henrique Ferreira de Freitas 
---
 meta/classes/boot-directdisk.bbclass | 65 ++--
 meta/classes/syslinux.bbclass|  5 +++
 2 files changed, 60 insertions(+), 10 deletions(-)

diff --git a/meta/classes/boot-directdisk.bbclass 
b/meta/classes/boot-directdisk.bbclass
index 8a55aae..4b9d7bd 100644
--- a/meta/classes/boot-directdisk.bbclass
+++ b/meta/classes/boot-directdisk.bbclass
@@ -31,6 +31,29 @@ EXCLUDE_FROM_WORLD = "1"
 BOOTDD_VOLUME_ID   ?= "boot"
 BOOTDD_EXTRA_SPACE ?= "16384"
 
+EFI = "${@base_contains("MACHINE_FEATURES", "efi", "1", "0", d)}"
+EFI_CLASS = "${@base_contains("MACHINE_FEATURES", "efi", "grub-efi", "", d)}"
+
+# Include legacy boot if MACHINE_FEATURES includes "pcbios" or if it does not
+# contain "efi". This way legacy is supported by default if neither is
+# specified, maintaining the original behavior.
+def pcbios(d):
+pcbios = base_contains("MACHINE_FEATURES", "pcbios", "1", "0", d)
+if pcbios == "0":
+pcbios = base_contains("MACHINE_FEATURES", "efi", "0", "1", d)
+return pcbios
+
+def pcbios_class(d):
+if d.getVar("PCBIOS", True) == "1":
+return "syslinux"
+return ""
+
+PCBIOS = "${@pcbios(d)}"
+PCBIOS_CLASS = "${@pcbios_class(d)}"
+
+inherit ${PCBIOS_CLASS}
+inherit ${EFI_CLASS}
+
 # Get the build_syslinux_cfg() function from the syslinux class
 
 AUTO_SYSLINUXCFG = "1"
@@ -38,17 +61,32 @@ DISK_SIGNATURE ?= "${DISK_SIGNATURE_GENERATED}"
 SYSLINUX_ROOT ?= "root=/dev/sda2"
 SYSLINUX_TIMEOUT ?= "10"
 
-inherit syslinux
-   
+populate() {
+   DEST=$1
+   install -d ${DEST}
+
+   # Install bzImage, initrd, and rootfs.img in DEST for all loaders to 
use.
+   install -m 0644 ${STAGING_KERNEL_DIR}/bzImage ${DEST}/vmlinuz
+
+   if [ -n "${INITRD}" ] && [ -s "${INITRD}" ]; then
+   install -m 0644 ${INITRD} ${DEST}/initrd
+   fi
+
+}
+
 build_boot_dd() {
HDDDIR="${S}/hdd/boot"
HDDIMG="${S}/hdd.image"
IMAGE=${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.hdddirect
 
-   install -d $HDDDIR
-   install -m 0644 ${STAGING_KERNEL_DIR}/bzImage $HDDDIR/vmlinuz
-   install -m 0644 ${S}/syslinux.cfg $HDDDIR/syslinux.cfg
-   install -m 444 ${STAGING_DATADIR}/syslinux/ldlinux.sys 
$HDDDIR/ldlinux.sys
+   populate ${HDDDIR}
+
+   if [ "${PCBIOS}" = "1" ]; then
+   syslinux_hddimg_populate
+   fi
+   if [ "${EFI}" = "1" ]; then
+   grubefi_hddimg_populate
+   fi
 
BLOCKS=`du -bks $HDDDIR | cut -f 1`
BLOCKS=`expr $BLOCKS + ${BOOTDD_EXTRA_SPACE}`
@@ -62,7 +100,9 @@ build_boot_dd() {
mkdosfs -n ${BOOTDD_VOLUME_ID} -S 512 -C $HDDIMG $BLOCKS 
mcopy -i $HDDIMG -s $HDDDIR/* ::/
 
-   syslinux $HDDIMG
+   if [ "${PCBIOS}" = "1" ]; then
+   syslinux_hdddirect_install $HDDIMG
+   fi  
chmod 644 $HDDIMG
 
ROOTFSBLOCKS=`du -Lbks ${ROOTFS} | cut -f 1`
@@ -85,9 +125,11 @@ build_boot_dd() {
dd of=$IMAGE bs=1 seek=440 conv=notrunc
 
OFFSET=`expr $END2 / 512`
-   dd if=${STAGING_DATADIR}/syslinux/mbr.bin of=$IMAGE conv=notrunc
+   if [ "${PCBIOS}" = "1" ]; then
+   dd if=${STAGING_DATADIR}/syslinux/mbr.bin of=$IMAGE conv=notrunc
+   fi
dd if=$HDDIMG of=$IMAGE conv=notrunc seek=1 bs=512
-   dd if=${ROOTFS} of=$IMAGE conv=notrunc seek=$OFFSET bs=512
+   dd if=${ROOTFS} of=$IMAGE conv=notrunc seek=$OFFSET bs=512  
 
cd ${DEPLOY_DIR_IMAGE}
rm -f ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.hdddirect
@@ -96,7 +138,10 @@ build_boot_dd() {
 
 python do_bootdirectdisk() {
 validate_disk_signature(d)
-bb.build.exec_func('build_syslinux_cfg', d)
+if d.getVar("PCBIOS", True) == "1":
+bb.build.exec_func('build_syslinux_cfg', d)
+if d.getVar("EFI", True) == "1":
+bb.build.exec_func('build_grub_cfg', d)
 bb.build.exec_func('build_boot_dd', d)
 }
 
diff --git a/meta/classes/syslinux.bbclass b/meta/classes/syslinux.bbclass
index 501bc6d..dae6609 100644
--- a/meta/classes/syslinux.bbclass
+++ b/meta/classes/syslinux.bbclass
@@ -64,6 +64,11 @@ syslinux_hddimg_install() {
syslinux ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.hddimg
 }
 
+syslinux_hdddirect_install() {
+   DEST=$1
+   syslinux $DEST
+}
+
 python build_syslinux_cfg () {
 import copy
 import sys
-- 
1.8.1.2

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v4] libtool: fix resolve of lt_sysroot

[Hans Beckerus]

On 2013-09-12 8:02, Hans Beckérus wrote:

On Thu, Sep 12, 2013 at 7:09 PM, Saul Wold  wrote:

On 09/11/2013 09:05 AM, Hans Beckérus wrote:

On Wed, Sep 11, 2013 at 10:15 AM, Hans Beckérus 
wrote:

On Tue, Sep 10, 2013 at 11:33 PM, Saul Wold  wrote:

On 09/10/2013 07:56 AM, hans.becke...@gmail.com wrote:


From: Hans Beckerus 

This patch updates libtool.m4 (and its output) to resolve a problem
with variable 'lt_sysroot' not being properly updated if the option
'--with[-libtool]-sysroot' is not provided when running the 'configure'
script for a package.

According to the help text ouput from 'configure':
--with-libtool-sysroot=DIR Search for dependent libraries within DIR
  (or the compiler's sysrooot if not specified).

Due to swapped cases in a switch statement, when checking if the option
was specified or not, wrong actions were taken resulting in an
incorrect sysroot and failures to properly locate e.g. .la files.


What kind of testing have you done with this?  Have you tried a full
world
build?  This kind of change scares me a little as what issues we might
have
patched around or behavior built into software.


In the area of testing, it has been verified in my local environment,
which covers a few different ARM based images and SDK installs. I have
not done a build of all possible packages in my Yocto branch.


I just completed a world build locally and have failures in file-native
guile-native, and gtk+3, not sure if we need to invalidate sstate, I am
starting a clean build.


I have no issues with neither of those packages, at least not in
stand-alone builds.
Can you specify a little more exactly what goes wrong during the build
stage?


Actually, someone else here hit a couple of packages that had  SDK
build failures after applying the patch.
In this case it was gettext-native and gnutls-native. After doing a
'cleanall' of those packages rebuild went fine.
So, yes, sstate should probably be invalidated after a change like
this since some packages does not seem to be rebuilt properly
otherwise. Are they missing a DEPEND to libtool maybe?


No, these are from a clean build space with no sstate either, I wanted to
verify that.

Also, anything that inherits autotools automagically gets a libtool
dependency added, so we should not be adding that kind of dependency in
recipes.

I have attached the 3 failures I saw for a completely clean build, note
these are native tools: file-native, guile-native and apr-util-native.


Again, I have no issues what so ever to build these packages one by
one after a clean sstate.
On the other hand, I am on a poky 1.4 baseline. I need to bring in the
latest oe-core and build world from there.
I have now tried a world build on oe-core master/latest and I can 
confirm that also I get build errors on a clean build root.
I only went as far as stopping at file-native. I think I need to debug 
this problem package by package. Something is definitely spooky here.
On poky 1.4 it works like a charm, on current oe-core it does not. Also, 
doing a clean sstate or building "file-native" separately
makes no difference.  What I discovered is that the sysroot is 
completely wrong. It has been resolved to "/" which means the wrong
set of libraries are picked up. If I patched the generated 
x86_64-linux-libtool and replaced lt_sysroot with the actual sysroot in use
compilation went fine! The libtool patch *is* good. No question about 
that. It is an obvious bug that has been corrected. To me this looks like

some kind of  a double-fault! I need to dig deeper.

Thanks.
Hans


Hans


Sau!



Thanks,
Hans


I have not dug too deeply into this yet.

Sau!





For current upstream status see:
http://lists.gnu.org/archive/html/bug-libtool/2013-09/msg5.html

Signed-off-by: Hans Beckerus 
---
meta/recipes-devtools/libtool/libtool-2.4.2.inc|  1 +
.../libtool/libtool/fix-resolve-lt-sysroot.patch   | 35
++
2 files changed, 36 insertions(+)
create mode 100644
meta/recipes-devtools/libtool/libtool/fix-resolve-lt-sysroot.patch

diff --git a/meta/recipes-devtools/libtool/libtool-2.4.2.inc
b/meta/recipes-devtools/libtool/libtool-2.4.2.inc
index bb4ddf0..92e4949 100644
--- a/meta/recipes-devtools/libtool/libtool-2.4.2.inc
+++ b/meta/recipes-devtools/libtool/libtool-2.4.2.inc
@@ -20,6 +20,7 @@ SRC_URI = "${GNU_MIRROR}/libtool/libtool-${PV}.tar.gz
\
 file://respect-fstack-protector.patch \
   file://norm-rpath.patch \
   file://dont-depend-on-help2man.patch \
+   file://fix-resolve-lt-sysroot.patch \
  "

SRC_URI[md5sum] = "d2f3b7d4627e69e13514a40e72a24d50"
diff --git
a/meta/recipes-devtools/libtool/libtool/fix-resolve-lt-sysroot.patch
b/meta/recipes-devtools/libtool/libtool/fix-resolve-lt-sysroot.patch
new file mode 100644
index 000..5a6335b
--- /dev/null
+++
b/meta/recipes-devtools/libtool/libtool/fix-resolve-lt-sysroot.patch
@@ -0,0 +1,35 @@
+
+Upstream-Status: Pending
+
+T

Re: [OE-core] [PATCH 3/5] grub-efi-native: Add support for EFI ISO images

[Darren Hart]

On Thu, 2013-09-12 at 12:19 -0500, Jason Wessel wrote:
> The iso9660 file system support needs to be added to grub in order to
> be able to correctly find the grub.cfg.  The grub commands to locate
> the grub.cfg also needs to be encoded into grub's default
> configuration.
> 
> This change allows the resulting grub binary to work both in the hard
> drive / USB boot case or the optical media boot case.
> 



> [YOCTO #4100]
> 
> Signed-off-by: Jason Wessel 
> ---
>  meta/recipes-bsp/grub/grub-efi-native_2.00.bb |8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/recipes-bsp/grub/grub-efi-native_2.00.bb 
> b/meta/recipes-bsp/grub/grub-efi-native_2.00.bb
> index 2d3d68a..3cff838 100644
> --- a/meta/recipes-bsp/grub/grub-efi-native_2.00.bb
> +++ b/meta/recipes-bsp/grub/grub-efi-native_2.00.bb
> @@ -66,9 +66,13 @@ EXTRA_OECONF = "--with-platform=efi --disable-grub-mkfont \
>  --enable-liblzma=no --enable-device-mapper=no 
> --enable-libzfs=no"
>  
>  do_mkimage() {
> - ./grub-mkimage -p /EFI/BOOT -d ./grub-core/ \
> + # Search for the grub.cfg on the local boot media with built in config 
> file
> + echo 'search.file /EFI/BOOT/grub.cfg root' > cfg\
> + echo 'set prefix=($root)/EFI/BOOT' >> cfg

Hrm, I think adding a cfg as a file via the SRC_URI would be preferable
to dynamically creating it every time. This would make it easier to
modify the config in the future.

Otherwise, looks good. 

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] Enable ptest support for lttng.

[Stefan Seefeld]

On 2013-09-12 14:12, Christian Babeux wrote:
> Hi Stefan,
>
>> +
>> +make -C tests installcheck
>> +
> A majority of the tests will probably fail this way. As of now, most
> tests assumes that they are being runned in the build tree and expect
> binaries to be at specific paths. We will have to fix this upstream if
> you want to integrate our testsuite with ptest.

That's right, in my tests only the "unit_tests" suite ran without
issues. The "fast_regressions" suite had many more failures than when
run as part of the 'check' target. (See my mail to the lttng list for more.)

Still, I think it's good to include these tests. If anything they may
just provide more motivation to address the underlying issue. :-)
>> ++prove --merge -v --exec '' - < $1 | sed \
>> ++  -e 's|^ok \(.*\)|PASS: \1|' \
>> ++  -e 's|^not ok \(.*\)|FAIL: \1|' \
>> ++  | egrep -h 'PASS|FAIL'
> This is sadly needed because we are using TAP as our standardized test
> output format across the multiples lttng codebases.

Do you think it would be worthwhile submitting this patch upstream ?
(The output format of prove is not the easiest to understand, and even
with the above some information may be lost. A more robust fix would
probably include a dedicated TAP formatter plugin
(http://perldoc.perl.org/TAP/Formatter/Console.html) that produces
ptest-compatible output.

Stefan

-- 

  ...ich hab' noch einen Koffer in Berlin...

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/5] bootimage.bbclass: Move fat image creation into a function

[Jason Wessel]

In order to call the fat image creation multiple times it needs to be
in its own function.  A future commit will make use of the new
function to additionally create EFI image files for use with an ISO.

[YOCTO #4100]

Signed-off-by: Jason Wessel 
---
 meta/classes/bootimg.bbclass |  110 ++
 1 file changed, 58 insertions(+), 52 deletions(-)

diff --git a/meta/classes/bootimg.bbclass b/meta/classes/bootimg.bbclass
index b312e0d..2ed7017 100644
--- a/meta/classes/bootimg.bbclass
+++ b/meta/classes/bootimg.bbclass
@@ -128,6 +128,63 @@ build_iso() {
ln -s ${IMAGE_NAME}.iso ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.iso
 }
 
+build_fat_img() {
+   FATSOURCEDIR=$1
+   FATIMG=$2
+
+   # Calculate the size required for the final image including the
+   # data and filesystem overhead.
+   # Sectors: 512 bytes
+   #  Blocks: 1024 bytes
+
+   # Determine the sector count just for the data
+   SECTORS=$(expr $(du --apparent-size -ks ${FATSOURCEDIR} | cut -f 1) \* 
2)
+
+   # Account for the filesystem overhead. This includes directory
+   # entries in the clusters as well as the FAT itself.
+   # Assumptions:
+   #   FAT32 (12 or 16 may be selected by mkdosfs, but the extra
+   #   padding will be minimal on those smaller images and not
+   #   worth the logic here to caclulate the smaller FAT sizes)
+   #   < 16 entries per directory
+   #   8.3 filenames only
+
+   # 32 bytes per dir entry
+   DIR_BYTES=$(expr $(find ${FATSOURCEDIR} | tail -n +2 | wc -l) \* 32)
+   # 32 bytes for every end-of-directory dir entry
+   DIR_BYTES=$(expr $DIR_BYTES + $(expr $(find ${FATSOURCEDIR} -type d | 
tail -n +2 | wc -l) \* 32))
+   # 4 bytes per FAT entry per sector of data
+   FAT_BYTES=$(expr $SECTORS \* 4)
+   # 4 bytes per FAT entry per end-of-cluster list
+   FAT_BYTES=$(expr $FAT_BYTES + $(expr $(find ${FATSOURCEDIR} -type d | 
tail -n +2 | wc -l) \* 4))
+
+   # Use a ceiling function to determine FS overhead in sectors
+   DIR_SECTORS=$(expr $(expr $DIR_BYTES + 511) / 512)
+   # There are two FATs on the image
+   FAT_SECTORS=$(expr $(expr $(expr $FAT_BYTES + 511) / 512) \* 2)
+   SECTORS=$(expr $SECTORS + $(expr $DIR_SECTORS + $FAT_SECTORS))
+
+   # Determine the final size in blocks accounting for some padding
+   BLOCKS=$(expr $(expr $SECTORS / 2) + ${BOOTIMG_EXTRA_SPACE})
+
+   # Ensure total sectors is an integral number of sectors per
+   # track or mcopy will complain. Sectors are 512 bytes, and we
+   # generate images with 32 sectors per track. This calculation is
+   # done in blocks, thus the mod by 16 instead of 32.
+   BLOCKS=$(expr $BLOCKS + $(expr 16 - $(expr $BLOCKS % 16)))
+
+   # mkdosfs will sometimes use FAT16 when it is not appropriate,
+   # resulting in a boot failure from SYSLINUX. Use FAT32 for
+   # images larger than 512MB, otherwise let mkdosfs decide.
+   if [ $(expr $BLOCKS / 1024) -gt 512 ]; then
+   FATSIZE="-F 32"
+   fi
+
+   mkdosfs ${FATSIZE} -n ${BOOTIMG_VOLUME_ID} -S 512 -C ${FATIMG} ${BLOCKS}
+   # Copy FATSOURCEDIR recursively into the image file directly
+   mcopy -i ${FATIMG} -s ${FATSOURCEDIR}/* ::/
+}
+
 build_hddimg() {
# Create an HDD image
if [ "${NOHDD}" != "1" ] ; then
@@ -140,58 +197,7 @@ build_hddimg() {
grubefi_hddimg_populate
fi
 
-   # Calculate the size required for the final image including the
-   # data and filesystem overhead.
-   # Sectors: 512 bytes
-   #  Blocks: 1024 bytes
-
-   # Determine the sector count just for the data
-   SECTORS=$(expr $(du --apparent-size -ks ${HDDDIR} | cut -f 1) 
\* 2)
-
-   # Account for the filesystem overhead. This includes directory
-   # entries in the clusters as well as the FAT itself.
-   # Assumptions:
-   #   FAT32 (12 or 16 may be selected by mkdosfs, but the extra
-   #   padding will be minimal on those smaller images and not
-   #   worth the logic here to caclulate the smaller FAT sizes)
-   #   < 16 entries per directory
-   #   8.3 filenames only
-
-   # 32 bytes per dir entry
-   DIR_BYTES=$(expr $(find ${HDDDIR} | tail -n +2 | wc -l) \* 32)
-   # 32 bytes for every end-of-directory dir entry
-   DIR_BYTES=$(expr $DIR_BYTES + $(expr $(find ${HDDDIR} -type d | 
tail -n +2 | wc -l) \* 32))
-   # 4 bytes per FAT entry per sector of data
-   FAT_BYTES=$(expr $SECTORS \* 4)
-   # 4 bytes per FAT entry per end-of-cluster list
-   FAT_BYTES=$(expr $FAT_BYTES + $(expr $(find ${HDDDIR} -type d | 
tail -n +2 | wc -l) \* 4))
-
-   # Use a ceiling function to determine FS over

Re: [OE-core] [PATCH 5/5] grub-efi.bbclass: Add serial and graphics menu options

[Jason Wessel]

On 09/12/2013 01:16 PM, Darren Hart wrote:
> On Thu, 2013-09-12 at 12:19 -0500, Jason Wessel wrote:
>> The syslinux.bbclass already has support for automatically generated
>> serial and graphics menu choices.  This patch adds the same concept to
>> the grub-efi menu.  That makes it possible to generate a single image
>> which can boot on a PCBIOS or EFI firmware with consistent looking
>> boot options.
>>
>> [YOCTO #4100]
>>
>> Signed-off-by: Jason Wessel 
>> ---
>>  meta/classes/grub-efi.bbclass |   41 
>> -
>>  meta/conf/machine/qemux86-64.conf |2 +-
>>  meta/conf/machine/qemux86.conf|2 ++
>>  3 files changed, 30 insertions(+), 15 deletions(-)
>>
>> diff --git a/meta/classes/grub-efi.bbclass b/meta/classes/grub-efi.bbclass
>> index c6f5d4e..c07e4a1 100644
>> --- a/meta/classes/grub-efi.bbclass
>> +++ b/meta/classes/grub-efi.bbclass
>> @@ -9,6 +9,7 @@
>>  # External variables
>>  # ${INITRD} - indicates a filesystem image to use as an initrd (optional)
>>  # ${ROOTFS} - indicates a filesystem image to include as the root 
>> filesystem (optional)
>> +# ${GRUB_GFXSERIAL} - set this to 1 to have graphics and serial in the boot 
>> menu
>>  # ${LABELS} - a list of targets for the automatic config
>>  # ${APPEND} - an override list of append strings for each label
>>  # ${GRUB_OPTS} - additional options to add to the config, ';' delimited # 
>> (optional)
>> @@ -16,6 +17,7 @@
>>  
>>  do_bootimg[depends] += "grub-efi-${TRANSLATED_TARGET_ARCH}-native:do_deploy"
>>  
>> +GRUB_SERIAL ?= "console=ttyS0,115200"
>>  GRUBCFG = "${S}/grub.cfg"
>>  GRUB_TIMEOUT ?= "10"
>>  #FIXME: build this from the machine config
>> @@ -55,6 +57,8 @@ python build_grub_cfg() {
>>  bb.error("WORKDIR not defined, unable to package")
>>  return
>>  
>> +gfxserial = d.getVar('GRUB_GFXSERIAL', True) or ""
>> +
>>  labels = d.getVar('LABELS', True)
>>  if not labels:
>>  bb.debug(1, "LABELS not defined, nothing to do")
>> @@ -88,6 +92,12 @@ python build_grub_cfg() {
>>  else:
>>  cfgfile.write('timeout=50\n')
>>  
>> +if gfxserial == "1":
>> +btypes = [ [ " graphics console", "console=tty0" ],
>> +[ " serial console", d.getVar('GRUB_SERIAL', True) or "" ] ]
>> +else:
>> +btypes = [ [ "", "" ] ]
>> +
>>  for label in labels.split():
>>  localdata = d.createCopy()
>>  
>> @@ -95,24 +105,27 @@ python build_grub_cfg() {
>>  if not overrides:
>>  raise bb.build.FuncFailed('OVERRIDES not defined')
>>  
>> -localdata.setVar('OVERRIDES', label + ':' + overrides)
>> -bb.data.update_data(localdata)
>> +for btype in btypes:
>> +localdata.setVar('OVERRIDES', label + ':' + overrides)
>> +bb.data.update_data(localdata)
>>  
>> -cfgfile.write('\nmenuentry \'%s\'{\n' % (label))
>> -if label == "install":
>> -label = "install-efi"
>> -cfgfile.write('linux /vmlinuz LABEL=%s' % (label))
>> +cfgfile.write('\nmenuentry \'%s%s\'{\n' % (label, btype[0]))
>> +lb = label
>> +if label == "install":
>> +lb = "install-efi"
>> +cfgfile.write('linux /vmlinuz LABEL=%s' % (lb))
>>  
>> -append = localdata.getVar('APPEND', True)
>> -initrd = localdata.getVar('INITRD', True)
>> +append = localdata.getVar('APPEND', True)
>> +initrd = localdata.getVar('INITRD', True)
>>  
>> -if append:
>> -cfgfile.write('%s' % (append))
>> -cfgfile.write('\n')
>> +if append:
>> +cfgfile.write('%s' % (append))
>> +cfgfile.write(' %s' % btype[1])
>> +cfgfile.write('\n')
>>  
>> -if initrd:
>> -cfgfile.write('initrd /initrd')
>> -cfgfile.write('\n}\n')
>> +if initrd:
>> +cfgfile.write('initrd /initrd')
>> +cfgfile.write('\n}\n')
>>  
>>  cfgfile.close()
>>  }
> 
> I'm not very familiar with the cfgfile for menus and such, so I don't
> have much to add. The one thing that catches me by surprise is the need
> for the serial device. On EFI systems, grub here uses the EFI console
> service, so if that uses the serial port you get it for free, no need
> for GRUB to try and use it directly. In fact does the above not
> cause some kind of conflict between the EFI console service and grub
> serial?
> 

In part that is why it is optional.   With respect to the serial bits, these 
are only the kernel boot arguments we are talking about.  It doesn't seem that 
there is a "primary" display interface for the HCDP in the EFI firmware I have. 
  Additionally, the kernel throws the EFI serial console under the bus at ACPI 
probe time, while this certainly could also be a bug in the firmware I have on 
my test board, the only way to keep the serial port alive for a login and the 
kernel boot information was 

Re: [OE-core] [PATCH 1/1] ptest-runner: trivial fixes and refine

[Chris Larson]

On Wed, Sep 11, 2013 at 2:17 AM,  wrote:

> +for x in `find -L ./ -name run-ptest -type f -perm /u+x,g+x`
> +do
>

As far as I can tell, busybox find doesn't support -L, so this adds an
implicit, undeclared dependency upon findutils.
-- 
Christopher Larson
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 4/5] bootimage.bbclass: Improve EFI & PCBIOS+EFI ISO support

[Jason Wessel]

On 09/12/2013 01:09 PM, Darren Hart wrote:
> On Thu, 2013-09-12 at 12:19 -0500, Jason Wessel wrote:
>> Using the latest mkisofs it is possible to generate 3 different types
>> of ISO images, which can be used in various scenarios.
>>
>> 1) PCBIOS Only ISO
>>- This option remains unchanged by this commit
>>- Uses syslinux menus
>>- Can be directly copied with dd to a USB device
>>- Can be burned to optical media
>>
>> 2) EFI Only ISO
>>- Uses grub 2 menus
>>- Can be burned to optical media
>>- If you want to use this image on a USB device
>>  extra steps must be taken in order to format the USB
>>  device with fat32, and copy an EFI loader which will
>>  in turn load the iso image
>>
>> 3) PCBIOS / EFI ISO
>>- This is a hybrid image ISO that will work for case 1 or 2
>>  as above with the same restrictions and boot menu types
>>  depending on what type of firmware is installed on
>>  the hardware or depending on if EFI or "Legacy Boot" is
>>  enabled on some UEFI firmwares.
>>
>> [YOCTO #4100]
>>
>> Signed-off-by: Jason Wessel 
>> ---
>>  meta/classes/bootimg.bbclass |   37 ++---
>>  1 file changed, 34 insertions(+), 3 deletions(-)
>>
>> diff --git a/meta/classes/bootimg.bbclass b/meta/classes/bootimg.bbclass
>> index 2ed7017..b4301e8 100644
>> --- a/meta/classes/bootimg.bbclass
>> +++ b/meta/classes/bootimg.bbclass
>> @@ -35,6 +35,7 @@ EXCLUDE_FROM_WORLD = "1"
>>  
>>  HDDDIR = "${S}/hddimg"
>>  ISODIR = "${S}/iso"
>> +EFIIMGDIR = "${S}/efi_img"
>>  COMPACT_ISODIR = "${S}/iso.z"
>>  
>>  BOOTIMG_VOLUME_ID   ?= "boot"
>> @@ -109,19 +110,49 @@ build_iso() {
>>  mkisofs_opts="-R -z -D -l"
>>  fi
>>  
> 
> Am I missing a patch? I don't have this mkisofs_opts in my
> bootimg.bbclass
> 

Yes


> How are $mkisofs_opts and ${MKISOFS_OPTIONS} related? Do we need both?
> 

Yes.

I built this patch set on top of the zisofs support I posted a day or so ago.  
I'll include that patch in the series next time, else it would create merge 
conflicts.


The piece from the other patch is:

 +   if [ "${COMPRESSISO}" = "1" ] ; then
 +   # create compact directory, compress iso
 +   mkdir -p ${COMPACT_ISODIR}
 +   mkzftree -z 9 -p 4 -F ${ISODIR}/rootfs.img 
${COMPACT_ISODIR}/rootfs.img
 +
 +   # move compact iso to iso, then remove compact directory
 +   mv ${COMPACT_ISODIR}/rootfs.img ${ISODIR}/rootfs.img
 +   rm -Rf ${COMPACT_ISODIR}
 +   mkisofs_opts="-r"
 +   else
 +   mkisofs_opts="-R -z -D -l"
 +   fi
 +


The zisofs is a big win for some folks because it will cut their image size in 
1/2 so they can use single layer media instead of dual layer media for example. 



>> -if [ "${PCBIOS}" = "1" ]; then
>> +if [ "${EFI}" = "1" ] ; then
>> +# Build a EFI directory to create efi.img
>> +mkdir -p ${EFIIMGDIR}/${EFIDIR}
>> +cp ${ISODIR}/${EFIDIR}/* ${EFIIMGDIR}${EFIDIR}
>> +cp ${ISODIR}/vmlinuz ${EFIIMGDIR}
>> +GRUB_IMAGE="bootia32.efi"
>> +if [ "${TARGET_ARCH}" = "x86_64" ]; then
>> +GRUB_IMAGE="bootx64.efi"
>> +fi
>> +echo "EFI\\BOOT\\${GRUB_IMAGE}" > ${EFIIMGDIR}/startup.nsh
>> +if [ -f "${ISODIR}/initrd" ] ; then
>> +cp ${ISODIR}/initrd ${EFIIMGDIR}
>> +fi
>> +build_fat_img ${EFIIMGDIR} ${ISODIR}/efi.img
>> +fi
>> +
>> +# Three ways to build the media
>> +if [ "${PCBIOS}" = "1" -a "${EFI}" = "1" ]; then
> 
> Per the Dash as BinSh wiki, the -a syntax is discouraged, best practices
> seem to be the use of && and || instead:
> 
> if ([ "${PCBIOS}" = "1" ] && [ "${EFI}" = "1" ]); then
> 


Noted for the future :-)


> 
>> +# 1) Build EFI + PCBIOS hybrid
>> +mkisofs -A ${BOOTIMG_VOLUME_ID} -V ${BOOTIMG_VOLUME_ID} \
>> +-o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso \
>> +-b ${ISO_BOOTIMG} -c ${ISO_BOOTCAT} $mkisofs_opts \
>> +${MKISOFS_OPTIONS} \
>> +-eltorito-alt-boot -eltorito-platform efi \
>> +-b efi.img -no-emul-boot \
>> +${ISODIR}
> 
> Has this been verified on any 32 bit PCBIOS platforms?


Yes, on tunnel creek based hardware. 


> It was my understanding the many 32 bit PCBIOS systems had very buggy
> el-torito support and didn't deal well with multiple el-torito images on
> the same disk. Although... looking at the command above, I'm not sure
> you're doing this with mutliple images. Do you have the syslinux and the
> efi image combined in the same efi.img?


My testing showed it worked for both EFI only and EFI+PCBIOS.  In the case of 
the EFI+PCBIOS image there are two eltorito images, but in the case of the EFI 
only, there is only one, so at least you have two options.  The 

Re: [OE-core] [PATCH 5/5] grub-efi.bbclass: Add serial and graphics menu options

[Darren Hart]

On Thu, 2013-09-12 at 11:01 -0700, Saul Wold wrote:
> On 09/12/2013 10:19 AM, Jason Wessel wrote:
> > The syslinux.bbclass already has support for automatically generated
> > serial and graphics menu choices.  This patch adds the same concept to
> > the grub-efi menu.  That makes it possible to generate a single image
> > which can boot on a PCBIOS or EFI firmware with consistent looking
> > boot options.
> >
> > [YOCTO #4100]
> >
> > Signed-off-by: Jason Wessel 
> > ---
> >   meta/classes/grub-efi.bbclass |   41 
> > -
> >   meta/conf/machine/qemux86-64.conf |2 +-
> >   meta/conf/machine/qemux86.conf|2 ++
> >   3 files changed, 30 insertions(+), 15 deletions(-)
> >
> > diff --git a/meta/classes/grub-efi.bbclass b/meta/classes/grub-efi.bbclass
> > index c6f5d4e..c07e4a1 100644
> > --- a/meta/classes/grub-efi.bbclass
> > +++ b/meta/classes/grub-efi.bbclass
> > @@ -9,6 +9,7 @@
> >   # External variables
> >   # ${INITRD} - indicates a filesystem image to use as an initrd (optional)
> >   # ${ROOTFS} - indicates a filesystem image to include as the root 
> > filesystem (optional)
> > +# ${GRUB_GFXSERIAL} - set this to 1 to have graphics and serial in the 
> > boot menu
> >   # ${LABELS} - a list of targets for the automatic config
> >   # ${APPEND} - an override list of append strings for each label
> >   # ${GRUB_OPTS} - additional options to add to the config, ';' delimited # 
> > (optional)
> > @@ -16,6 +17,7 @@
> >
> >   do_bootimg[depends] += 
> > "grub-efi-${TRANSLATED_TARGET_ARCH}-native:do_deploy"
> >
> > +GRUB_SERIAL ?= "console=ttyS0,115200"
> >   GRUBCFG = "${S}/grub.cfg"
> >   GRUB_TIMEOUT ?= "10"
> >   #FIXME: build this from the machine config
> > @@ -55,6 +57,8 @@ python build_grub_cfg() {
> >   bb.error("WORKDIR not defined, unable to package")
> >   return
> >
> > +gfxserial = d.getVar('GRUB_GFXSERIAL', True) or ""
> > +
> >   labels = d.getVar('LABELS', True)
> >   if not labels:
> >   bb.debug(1, "LABELS not defined, nothing to do")
> > @@ -88,6 +92,12 @@ python build_grub_cfg() {
> >   else:
> >   cfgfile.write('timeout=50\n')
> >
> > +if gfxserial == "1":
> > +btypes = [ [ " graphics console", "console=tty0" ],
> > +[ " serial console", d.getVar('GRUB_SERIAL', True) or "" ] ]
> > +else:
> > +btypes = [ [ "", "" ] ]
> > +
> >   for label in labels.split():
> >   localdata = d.createCopy()
> >
> > @@ -95,24 +105,27 @@ python build_grub_cfg() {
> >   if not overrides:
> >   raise bb.build.FuncFailed('OVERRIDES not defined')
> >
> > -localdata.setVar('OVERRIDES', label + ':' + overrides)
> > -bb.data.update_data(localdata)
> > +for btype in btypes:
> > +localdata.setVar('OVERRIDES', label + ':' + overrides)
> > +bb.data.update_data(localdata)
> >
> > -cfgfile.write('\nmenuentry \'%s\'{\n' % (label))
> > -if label == "install":
> > -label = "install-efi"
> > -cfgfile.write('linux /vmlinuz LABEL=%s' % (label))
> > +cfgfile.write('\nmenuentry \'%s%s\'{\n' % (label, btype[0]))
> > +lb = label
> > +if label == "install":
> > +lb = "install-efi"
> > +cfgfile.write('linux /vmlinuz LABEL=%s' % (lb))
> >
> > -append = localdata.getVar('APPEND', True)
> > -initrd = localdata.getVar('INITRD', True)
> > +append = localdata.getVar('APPEND', True)
> > +initrd = localdata.getVar('INITRD', True)
> >
> > -if append:
> > -cfgfile.write('%s' % (append))
> > -cfgfile.write('\n')
> > +if append:
> > +cfgfile.write('%s' % (append))
> > +cfgfile.write(' %s' % btype[1])
> > +cfgfile.write('\n')
> >
> > -if initrd:
> > -cfgfile.write('initrd /initrd')
> > -cfgfile.write('\n}\n')
> > +if initrd:
> > +cfgfile.write('initrd /initrd')
> > +cfgfile.write('\n}\n')
> >
> >   cfgfile.close()
> >   }
> > diff --git a/meta/conf/machine/qemux86-64.conf 
> > b/meta/conf/machine/qemux86-64.conf
> > index c572225..6f68410 100644
> > --- a/meta/conf/machine/qemux86-64.conf
> > +++ b/meta/conf/machine/qemux86-64.conf
> > @@ -21,6 +21,6 @@ XSERVER = "xserver-xorg \
> >  xf86-input-evdev \
> >  xf86-video-vmware"
> >
> > -MACHINE_FEATURES += "x86"
> > +MACHINE_FEATURES += "x86 efi"
> >
> >   MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "v86d"
> > diff --git a/meta/conf/machine/qemux86.conf b/meta/conf/machine/qemux86.conf
> > index 94ee573..57a9a50 100644
> > --- a/meta/conf/machine/qemux86.conf
> > +++ b/meta/conf/machine/qemux86.conf
> > @@ -22,5 +22,7 @@ XSERVER = "xserver-xorg \
> >  xf86-video-vmware"
> >
> >   MACHINE_FEATURES += "x86"
> > +MACHINE_FEATURES += "efi"
> > +#MACHINE_FEATURES += "pcbios"
> >

Re: [OE-core] [PATCH 4/5] bootimage.bbclass: Improve EFI & PCBIOS+EFI ISO support

[Darren Hart]

On Thu, 2013-09-12 at 12:19 -0500, Jason Wessel wrote:
> Using the latest mkisofs it is possible to generate 3 different types
> of ISO images, which can be used in various scenarios.
> 
> 1) PCBIOS Only ISO
>- This option remains unchanged by this commit
>- Uses syslinux menus
>- Can be directly copied with dd to a USB device
>- Can be burned to optical media
> 
> 2) EFI Only ISO
>- Uses grub 2 menus
>- Can be burned to optical media
>- If you want to use this image on a USB device
>  extra steps must be taken in order to format the USB
>  device with fat32, and copy an EFI loader which will
>  in turn load the iso image
> 
> 3) PCBIOS / EFI ISO
>- This is a hybrid image ISO that will work for case 1 or 2
>  as above with the same restrictions and boot menu types
>  depending on what type of firmware is installed on
>  the hardware or depending on if EFI or "Legacy Boot" is
>  enabled on some UEFI firmwares.
> 
> [YOCTO #4100]
> 
> Signed-off-by: Jason Wessel 
> ---
>  meta/classes/bootimg.bbclass |   37 ++---
>  1 file changed, 34 insertions(+), 3 deletions(-)
> 
> diff --git a/meta/classes/bootimg.bbclass b/meta/classes/bootimg.bbclass
> index 2ed7017..b4301e8 100644
> --- a/meta/classes/bootimg.bbclass
> +++ b/meta/classes/bootimg.bbclass
> @@ -35,6 +35,7 @@ EXCLUDE_FROM_WORLD = "1"
>  
>  HDDDIR = "${S}/hddimg"
>  ISODIR = "${S}/iso"
> +EFIIMGDIR = "${S}/efi_img"
>  COMPACT_ISODIR = "${S}/iso.z"
>  
>  BOOTIMG_VOLUME_ID   ?= "boot"
> @@ -109,19 +110,49 @@ build_iso() {
>   mkisofs_opts="-R -z -D -l"
>   fi
>  

Am I missing a patch? I don't have this mkisofs_opts in my
bootimg.bbclass

How are $mkisofs_opts and ${MKISOFS_OPTIONS} related? Do we need both?

> - if [ "${PCBIOS}" = "1" ]; then
> + if [ "${EFI}" = "1" ] ; then
> + # Build a EFI directory to create efi.img
> + mkdir -p ${EFIIMGDIR}/${EFIDIR}
> + cp ${ISODIR}/${EFIDIR}/* ${EFIIMGDIR}${EFIDIR}
> + cp ${ISODIR}/vmlinuz ${EFIIMGDIR}
> + GRUB_IMAGE="bootia32.efi"
> + if [ "${TARGET_ARCH}" = "x86_64" ]; then
> + GRUB_IMAGE="bootx64.efi"
> + fi
> + echo "EFI\\BOOT\\${GRUB_IMAGE}" > ${EFIIMGDIR}/startup.nsh
> + if [ -f "${ISODIR}/initrd" ] ; then
> + cp ${ISODIR}/initrd ${EFIIMGDIR}
> + fi
> + build_fat_img ${EFIIMGDIR} ${ISODIR}/efi.img
> + fi
> +
> + # Three ways to build the media
> + if [ "${PCBIOS}" = "1" -a "${EFI}" = "1" ]; then

Per the Dash as BinSh wiki, the -a syntax is discouraged, best practices
seem to be the use of && and || instead:

if ([ "${PCBIOS}" = "1" ] && [ "${EFI}" = "1" ]); then


> + # 1) Build EFI + PCBIOS hybrid
> + mkisofs -A ${BOOTIMG_VOLUME_ID} -V ${BOOTIMG_VOLUME_ID} \
> + -o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso \
> + -b ${ISO_BOOTIMG} -c ${ISO_BOOTCAT} $mkisofs_opts \
> + ${MKISOFS_OPTIONS} \
> + -eltorito-alt-boot -eltorito-platform efi \
> + -b efi.img -no-emul-boot \
> + ${ISODIR}

Has this been verified on any 32 bit PCBIOS platforms?
It was my understanding the many 32 bit PCBIOS systems had very buggy
el-torito support and didn't deal well with multiple el-torito images on
the same disk. Although... looking at the command above, I'm not sure
you're doing this with mutliple images. Do you have the syslinux and the
efi image combined in the same efi.img?

Has this been verified to work on USB media?
It was explained to me that, at least for some implementations, if the
boot device selection code will not look for ISO9660 on anything that
doesn't have a block size of 2048, making it give up on a USB device
before even attempting to find the ISO9660 FS.



> + elif [ "${PCBIOS}" = "1" ] ; then
> + # 2) Build PCBIOS only media
>   mkisofs -V ${BOOTIMG_VOLUME_ID} \
>   -o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso \
>   -b ${ISO_BOOTIMG} -c ${ISO_BOOTCAT} $mkisofs_opts \
>   ${MKISOFS_OPTIONS} ${ISODIR}
>   else

This should also verify that we are building for EFI. !PCBIOS != EFI. If
none of these options eval to true, an error should be printed

> - bbnote "EFI-only ISO images are untested, please provide 
> feedback."
>   mkisofs -V ${BOOTIMG_VOLUME_ID} \
>   -o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso \
> + -eltorito-alt-boot -eltorito-platform efi \
> + -b efi.img -no-emul-boot \
>   -r ${ISODIR}
>   fi
>  
> - isohybrid ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso
> + if [ "${PCBIOS}" = "1" ]; then
> + isohybrid ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso
> + fi

A comm

Re: [OE-core] [PATCH 4/5] bootimage.bbclass: Improve EFI & PCBIOS+EFI ISO support

[Darren Hart]

On Thu, 2013-09-12 at 15:14 -0500, Jason Wessel wrote:
> On 09/12/2013 01:09 PM, Darren Hart wrote:
> > On Thu, 2013-09-12 at 12:19 -0500, Jason Wessel wrote:
> >> Using the latest mkisofs it is possible to generate 3 different types
> >> of ISO images, which can be used in various scenarios.
> >>
> >> 1) PCBIOS Only ISO
> >>- This option remains unchanged by this commit
> >>- Uses syslinux menus
> >>- Can be directly copied with dd to a USB device
> >>- Can be burned to optical media
> >>
> >> 2) EFI Only ISO
> >>- Uses grub 2 menus
> >>- Can be burned to optical media
> >>- If you want to use this image on a USB device
> >>  extra steps must be taken in order to format the USB
> >>  device with fat32, and copy an EFI loader which will
> >>  in turn load the iso image
> >>
> >> 3) PCBIOS / EFI ISO
> >>- This is a hybrid image ISO that will work for case 1 or 2
> >>  as above with the same restrictions and boot menu types
> >>  depending on what type of firmware is installed on
> >>  the hardware or depending on if EFI or "Legacy Boot" is
> >>  enabled on some UEFI firmwares.
> >>
> >> [YOCTO #4100]
> >>
> >> Signed-off-by: Jason Wessel 
> >> ---
> >>  meta/classes/bootimg.bbclass |   37 ++---
> >>  1 file changed, 34 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/meta/classes/bootimg.bbclass b/meta/classes/bootimg.bbclass
> >> index 2ed7017..b4301e8 100644
> >> --- a/meta/classes/bootimg.bbclass
> >> +++ b/meta/classes/bootimg.bbclass
> >> @@ -35,6 +35,7 @@ EXCLUDE_FROM_WORLD = "1"
> >>  
> >>  HDDDIR = "${S}/hddimg"
> >>  ISODIR = "${S}/iso"
> >> +EFIIMGDIR = "${S}/efi_img"
> >>  COMPACT_ISODIR = "${S}/iso.z"
> >>  
> >>  BOOTIMG_VOLUME_ID   ?= "boot"
> >> @@ -109,19 +110,49 @@ build_iso() {
> >>mkisofs_opts="-R -z -D -l"
> >>fi
> >>  
> > 
> > Am I missing a patch? I don't have this mkisofs_opts in my
> > bootimg.bbclass
> > 
> 
> Yes
> 
> 
> > How are $mkisofs_opts and ${MKISOFS_OPTIONS} related? Do we need both?
> > 
> 
> Yes.
> 
> I built this patch set on top of the zisofs support I posted a day or
> so ago.  I'll include that patch in the series next time, else it
> would create merge conflicts.

OK, thanks.

> 
> 
> The piece from the other patch is:
> 
>  +   if [ "${COMPRESSISO}" = "1" ] ; then
>  +   # create compact directory, compress iso
>  +   mkdir -p ${COMPACT_ISODIR}
>  +   mkzftree -z 9 -p 4 -F ${ISODIR}/rootfs.img 
> ${COMPACT_ISODIR}/rootfs.img
>  +
>  +   # move compact iso to iso, then remove compact directory
>  +   mv ${COMPACT_ISODIR}/rootfs.img ${ISODIR}/rootfs.img
>  +   rm -Rf ${COMPACT_ISODIR}
>  +   mkisofs_opts="-r"
>  +   else
>  +   mkisofs_opts="-R -z -D -l"
>  +   fi
>  +
> 

So my objection here is the two variables are VERY similar in name and
there is no way to distinguish between them. Would it make sense to
either append to MKISOFS_OPTIONS above or to rename mkisofs_opts to
something like mkisofs_compression_opts to distinguish them.

> 
> The zisofs is a big win for some folks because it will cut their image
> size in 1/2 so they can use single layer media instead of dual layer
> media for example. 

Nice.

> 
> 
> 
> >> -  if [ "${PCBIOS}" = "1" ]; then
> >> +  if [ "${EFI}" = "1" ] ; then
> >> +  # Build a EFI directory to create efi.img
> >> +  mkdir -p ${EFIIMGDIR}/${EFIDIR}
> >> +  cp ${ISODIR}/${EFIDIR}/* ${EFIIMGDIR}${EFIDIR}
> >> +  cp ${ISODIR}/vmlinuz ${EFIIMGDIR}
> >> +  GRUB_IMAGE="bootia32.efi"
> >> +  if [ "${TARGET_ARCH}" = "x86_64" ]; then
> >> +  GRUB_IMAGE="bootx64.efi"
> >> +  fi
> >> +  echo "EFI\\BOOT\\${GRUB_IMAGE}" > ${EFIIMGDIR}/startup.nsh
> >> +  if [ -f "${ISODIR}/initrd" ] ; then
> >> +  cp ${ISODIR}/initrd ${EFIIMGDIR}
> >> +  fi
> >> +  build_fat_img ${EFIIMGDIR} ${ISODIR}/efi.img
> >> +  fi
> >> +
> >> +  # Three ways to build the media
> >> +  if [ "${PCBIOS}" = "1" -a "${EFI}" = "1" ]; then
> > 
> > Per the Dash as BinSh wiki, the -a syntax is discouraged, best practices
> > seem to be the use of && and || instead:
> > 
> > if ([ "${PCBIOS}" = "1" ] && [ "${EFI}" = "1" ]); then
> > 
> 
> 
> Noted for the future :-)


POSIX shell compatibility can be a bit of a hot-button with recipes.


> > 
> >> +  # 1) Build EFI + PCBIOS hybrid
> >> +  mkisofs -A ${BOOTIMG_VOLUME_ID} -V ${BOOTIMG_VOLUME_ID} \
> >> +  -o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso \
> >> +  -b ${ISO_BOOTIMG} -c ${ISO_BOOTCAT} $mkisofs_opts \
> >> +  ${MKISOFS_OPTIONS} \
> >> +  -eltorito-alt-boot -eltorito-platform efi \
> >> +  -b efi.img -no-emul-boot \
> >> +  ${ISODIR}
> > 
> > Has this been verified on any 32 bit PC

Re: [OE-core] [PATCH v4] libtool: fix resolve of lt_sysroot

[Hans Beckérus]

On Thu, Sep 12, 2013 at 7:09 PM, Saul Wold  wrote:
> On 09/11/2013 09:05 AM, Hans Beckérus wrote:
>>
>> On Wed, Sep 11, 2013 at 10:15 AM, Hans Beckérus 
>> wrote:
>>>
>>> On Tue, Sep 10, 2013 at 11:33 PM, Saul Wold  wrote:

 On 09/10/2013 07:56 AM, hans.becke...@gmail.com wrote:
>
>
> From: Hans Beckerus 
>
> This patch updates libtool.m4 (and its output) to resolve a problem
> with variable 'lt_sysroot' not being properly updated if the option
> '--with[-libtool]-sysroot' is not provided when running the 'configure'
> script for a package.
>
> According to the help text ouput from 'configure':
> --with-libtool-sysroot=DIR Search for dependent libraries within DIR
>  (or the compiler's sysrooot if not specified).
>
> Due to swapped cases in a switch statement, when checking if the option
> was specified or not, wrong actions were taken resulting in an
> incorrect sysroot and failures to properly locate e.g. .la files.
>
 What kind of testing have you done with this?  Have you tried a full
 world
 build?  This kind of change scares me a little as what issues we might
 have
 patched around or behavior built into software.

>>> In the area of testing, it has been verified in my local environment,
>>> which covers a few different ARM based images and SDK installs. I have
>>> not done a build of all possible packages in my Yocto branch.
>>>
 I just completed a world build locally and have failures in file-native
 guile-native, and gtk+3, not sure if we need to invalidate sstate, I am
 starting a clean build.

>>> I have no issues with neither of those packages, at least not in
>>> stand-alone builds.
>>> Can you specify a little more exactly what goes wrong during the build
>>> stage?
>>>
>> Actually, someone else here hit a couple of packages that had  SDK
>> build failures after applying the patch.
>> In this case it was gettext-native and gnutls-native. After doing a
>> 'cleanall' of those packages rebuild went fine.
>> So, yes, sstate should probably be invalidated after a change like
>> this since some packages does not seem to be rebuilt properly
>> otherwise. Are they missing a DEPEND to libtool maybe?
>>
> No, these are from a clean build space with no sstate either, I wanted to
> verify that.
>
> Also, anything that inherits autotools automagically gets a libtool
> dependency added, so we should not be adding that kind of dependency in
> recipes.
>
> I have attached the 3 failures I saw for a completely clean build, note
> these are native tools: file-native, guile-native and apr-util-native.
>
Again, I have no issues what so ever to build these packages one by
one after a clean sstate.
On the other hand, I am on a poky 1.4 baseline. I need to bring in the
latest oe-core and build world from there.

Hans

>
> Sau!
>
>
>>> Thanks,
>>> Hans
>>>
 I have not dug too deeply into this yet.

 Sau!




> For current upstream status see:
> http://lists.gnu.org/archive/html/bug-libtool/2013-09/msg5.html
>
> Signed-off-by: Hans Beckerus 
> ---
>meta/recipes-devtools/libtool/libtool-2.4.2.inc|  1 +
>.../libtool/libtool/fix-resolve-lt-sysroot.patch   | 35
> ++
>2 files changed, 36 insertions(+)
>create mode 100644
> meta/recipes-devtools/libtool/libtool/fix-resolve-lt-sysroot.patch
>
> diff --git a/meta/recipes-devtools/libtool/libtool-2.4.2.inc
> b/meta/recipes-devtools/libtool/libtool-2.4.2.inc
> index bb4ddf0..92e4949 100644
> --- a/meta/recipes-devtools/libtool/libtool-2.4.2.inc
> +++ b/meta/recipes-devtools/libtool/libtool-2.4.2.inc
> @@ -20,6 +20,7 @@ SRC_URI = "${GNU_MIRROR}/libtool/libtool-${PV}.tar.gz
> \
> file://respect-fstack-protector.patch \
>   file://norm-rpath.patch \
>   file://dont-depend-on-help2man.patch \
> +   file://fix-resolve-lt-sysroot.patch \
>  "
>
>SRC_URI[md5sum] = "d2f3b7d4627e69e13514a40e72a24d50"
> diff --git
> a/meta/recipes-devtools/libtool/libtool/fix-resolve-lt-sysroot.patch
> b/meta/recipes-devtools/libtool/libtool/fix-resolve-lt-sysroot.patch
> new file mode 100644
> index 000..5a6335b
> --- /dev/null
> +++
> b/meta/recipes-devtools/libtool/libtool/fix-resolve-lt-sysroot.patch
> @@ -0,0 +1,35 @@
> +
> +Upstream-Status: Pending
> +
> +This patch updates libtool.m4 (and its output) to resolve a problem
> +with variable 'lt_sysroot' not being properly updated if the option
> +'--with[-libtool]-sysroot' is not provided when running the
> 'configure'
> +script for a package.
> +
> +I have also reported the problem to libtool here
> +
> +http://lists.gnu.org/archive/html/bug-libtool/2013-09/msg5.html
> +
> +Signed-

Re: [OE-core] [PATCH 5/5] grub-efi.bbclass: Add serial and graphics menu options

[Jason Wessel]

On 09/12/2013 01:01 PM, Saul Wold wrote:
> On 09/12/2013 10:19 AM, Jason Wessel wrote:
>> The syslinux.bbclass already has support for automatically generated
>> serial and graphics menu choices.  This patch adds the same concept to
>> the grub-efi menu.  That makes it possible to generate a single image
>> which can boot on a PCBIOS or EFI firmware with consistent looking
>> boot options.
>>
>> [YOCTO #4100]
>>
>> Signed-off-by: Jason Wessel 
>> ---
>>   meta/classes/grub-efi.bbclass |   41 
>> -
>>   meta/conf/machine/qemux86-64.conf |2 +-
>>   meta/conf/machine/qemux86.conf|2 ++
>>   3 files changed, 30 insertions(+), 15 deletions(-)
>>
>> diff --git a/meta/classes/grub-efi.bbclass b/meta/classes/grub-efi.bbclass
>> index c6f5d4e..c07e4a1 100644
>> --- a/meta/classes/grub-efi.bbclass
>> +++ b/meta/classes/grub-efi.bbclass
>> @@ -9,6 +9,7 @@
>>   # External variables
>>   # ${INITRD} - indicates a filesystem image to use as an initrd (optional)
>>   # ${ROOTFS} - indicates a filesystem image to include as the root 
>> filesystem (optional)
>> +# ${GRUB_GFXSERIAL} - set this to 1 to have graphics and serial in the boot 
>> menu
>>   # ${LABELS} - a list of targets for the automatic config
>>   # ${APPEND} - an override list of append strings for each label
>>   # ${GRUB_OPTS} - additional options to add to the config, ';' delimited # 
>> (optional)
>> @@ -16,6 +17,7 @@
>>
>>   do_bootimg[depends] += 
>> "grub-efi-${TRANSLATED_TARGET_ARCH}-native:do_deploy"
>>
>> +GRUB_SERIAL ?= "console=ttyS0,115200"
>>   GRUBCFG = "${S}/grub.cfg"
>>   GRUB_TIMEOUT ?= "10"
>>   #FIXME: build this from the machine config
>> @@ -55,6 +57,8 @@ python build_grub_cfg() {
>>   bb.error("WORKDIR not defined, unable to package")
>>   return
>>
>> +gfxserial = d.getVar('GRUB_GFXSERIAL', True) or ""
>> +
>>   labels = d.getVar('LABELS', True)
>>   if not labels:
>>   bb.debug(1, "LABELS not defined, nothing to do")
>> @@ -88,6 +92,12 @@ python build_grub_cfg() {
>>   else:
>>   cfgfile.write('timeout=50\n')
>>
>> +if gfxserial == "1":
>> +btypes = [ [ " graphics console", "console=tty0" ],
>> +[ " serial console", d.getVar('GRUB_SERIAL', True) or "" ] ]
>> +else:
>> +btypes = [ [ "", "" ] ]
>> +
>>   for label in labels.split():
>>   localdata = d.createCopy()
>>
>> @@ -95,24 +105,27 @@ python build_grub_cfg() {
>>   if not overrides:
>>   raise bb.build.FuncFailed('OVERRIDES not defined')
>>
>> -localdata.setVar('OVERRIDES', label + ':' + overrides)
>> -bb.data.update_data(localdata)
>> +for btype in btypes:
>> +localdata.setVar('OVERRIDES', label + ':' + overrides)
>> +bb.data.update_data(localdata)
>>
>> -cfgfile.write('\nmenuentry \'%s\'{\n' % (label))
>> -if label == "install":
>> -label = "install-efi"
>> -cfgfile.write('linux /vmlinuz LABEL=%s' % (label))
>> +cfgfile.write('\nmenuentry \'%s%s\'{\n' % (label, btype[0]))
>> +lb = label
>> +if label == "install":
>> +lb = "install-efi"
>> +cfgfile.write('linux /vmlinuz LABEL=%s' % (lb))
>>
>> -append = localdata.getVar('APPEND', True)
>> -initrd = localdata.getVar('INITRD', True)
>> +append = localdata.getVar('APPEND', True)
>> +initrd = localdata.getVar('INITRD', True)
>>
>> -if append:
>> -cfgfile.write('%s' % (append))
>> -cfgfile.write('\n')
>> +if append:
>> +cfgfile.write('%s' % (append))
>> +cfgfile.write(' %s' % btype[1])
>> +cfgfile.write('\n')
>>
>> -if initrd:
>> -cfgfile.write('initrd /initrd')
>> -cfgfile.write('\n}\n')
>> +if initrd:
>> +cfgfile.write('initrd /initrd')
>> +cfgfile.write('\n}\n')
>>
>>   cfgfile.close()
>>   }
>> diff --git a/meta/conf/machine/qemux86-64.conf 
>> b/meta/conf/machine/qemux86-64.conf
>> index c572225..6f68410 100644
>> --- a/meta/conf/machine/qemux86-64.conf
>> +++ b/meta/conf/machine/qemux86-64.conf
>> @@ -21,6 +21,6 @@ XSERVER = "xserver-xorg \
>>  xf86-input-evdev \
>>  xf86-video-vmware"
>>
>> -MACHINE_FEATURES += "x86"
>> +MACHINE_FEATURES += "x86 efi"
>>
>>   MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "v86d"
>> diff --git a/meta/conf/machine/qemux86.conf b/meta/conf/machine/qemux86.conf
>> index 94ee573..57a9a50 100644
>> --- a/meta/conf/machine/qemux86.conf
>> +++ b/meta/conf/machine/qemux86.conf
>> @@ -22,5 +22,7 @@ XSERVER = "xserver-xorg \
>>  xf86-video-vmware"
>>
>>   MACHINE_FEATURES += "x86"
>> +MACHINE_FEATURES += "efi"
>> +#MACHINE_FEATURES += "pcbios"
>>
> Did you intend to keep the commented out like vs what you did above in 
> x86-64?
>
>>   MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "v86d"
>>
>

Re: [OE-core] [PATCH 5/5] grub-efi.bbclass: Add serial and graphics menu options

[Darren Hart]

On Thu, 2013-09-12 at 14:52 -0500, Jason Wessel wrote:
> On 09/12/2013 01:16 PM, Darren Hart wrote:
> > On Thu, 2013-09-12 at 12:19 -0500, Jason Wessel wrote:
> >> The syslinux.bbclass already has support for automatically generated
> >> serial and graphics menu choices.  This patch adds the same concept to
> >> the grub-efi menu.  That makes it possible to generate a single image
> >> which can boot on a PCBIOS or EFI firmware with consistent looking
> >> boot options.
> >>
> >> [YOCTO #4100]
> >>
> >> Signed-off-by: Jason Wessel 
> >> ---
> >>  meta/classes/grub-efi.bbclass |   41 
> >> -
> >>  meta/conf/machine/qemux86-64.conf |2 +-
> >>  meta/conf/machine/qemux86.conf|2 ++
> >>  3 files changed, 30 insertions(+), 15 deletions(-)
> >>
> >> diff --git a/meta/classes/grub-efi.bbclass b/meta/classes/grub-efi.bbclass
> >> index c6f5d4e..c07e4a1 100644
> >> --- a/meta/classes/grub-efi.bbclass
> >> +++ b/meta/classes/grub-efi.bbclass
> >> @@ -9,6 +9,7 @@
> >>  # External variables
> >>  # ${INITRD} - indicates a filesystem image to use as an initrd (optional)
> >>  # ${ROOTFS} - indicates a filesystem image to include as the root 
> >> filesystem (optional)
> >> +# ${GRUB_GFXSERIAL} - set this to 1 to have graphics and serial in the 
> >> boot menu
> >>  # ${LABELS} - a list of targets for the automatic config
> >>  # ${APPEND} - an override list of append strings for each label
> >>  # ${GRUB_OPTS} - additional options to add to the config, ';' delimited # 
> >> (optional)
> >> @@ -16,6 +17,7 @@
> >>  
> >>  do_bootimg[depends] += 
> >> "grub-efi-${TRANSLATED_TARGET_ARCH}-native:do_deploy"
> >>  
> >> +GRUB_SERIAL ?= "console=ttyS0,115200"

...

> > I'm not very familiar with the cfgfile for menus and such, so I don't
> > have much to add. The one thing that catches me by surprise is the need
> > for the serial device. On EFI systems, grub here uses the EFI console
> > service, so if that uses the serial port you get it for free, no need
> > for GRUB to try and use it directly. In fact does the above not
> > cause some kind of conflict between the EFI console service and grub
> > serial?
> > 
> 
> In part that is why it is optional.   With respect to the serial bits,
> these are only the kernel boot arguments we are talking about.  It


Hrm this should be handled with APPEND parameter from the machine
configs, not a new GRUB_SERIAL statement


>  doesn't seem that there is a "primary" display interface for the HCDP
> in the EFI firmware I have.   Additionally, the kernel throws the EFI
> serial console under the bus at ACPI probe time, while this certainly
> could also be a bug in the firmware I have on my test board, the only
> way to keep the serial port alive for a login and the kernel boot
> information was to specify console=ttyS0...

Hrm interesting. I guess we'll just need to test more broadly.
Indeed the kernel should be using it's own console= parameter, but
again, that should come from the APPEND_machine variable.


> I have yet another system I need to try this on which has a much newer
> UEFI and a serial port, but I thought it would be best to get
> something out there that covers the "buggy firmwares" as well which
> can be built optionally.

Agreed, so long as it doesn't break the common case.


> > Both of the following should be in a separate patch. In fact, they
> > should probably have a qemux86-common.inc which took care of most of
> > this (as was done recently for genericx86-common.inc).
> 
> 
> So I am not sure that we want to patch up the qemux86* conf files at
> all.  Do we want to enable EFI + PCBIOS all the time now that we have
> a way to generate images (noting these images will work with runqemu)?
> I figured I would just drop those modifications entirely.  I would
> expect something like a "all encompassing" white box BSP to select
> both, but for the qemux86*, I don't think it makes sense.
> 

At some point we want qemux86* to boot with OVMF, but we can add "efi"
to MACHINE_FEATURES when/if that becomes doable with oe-core. So yeah,
go ahead and just drop these entirely for now.

...

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 5/5] grub-efi.bbclass: Add serial and graphics menu options

[Saul Wold]

On 09/12/2013 10:19 AM, Jason Wessel wrote:

The syslinux.bbclass already has support for automatically generated
serial and graphics menu choices.  This patch adds the same concept to
the grub-efi menu.  That makes it possible to generate a single image
which can boot on a PCBIOS or EFI firmware with consistent looking
boot options.

[YOCTO #4100]

Signed-off-by: Jason Wessel 
---
  meta/classes/grub-efi.bbclass |   41 -
  meta/conf/machine/qemux86-64.conf |2 +-
  meta/conf/machine/qemux86.conf|2 ++
  3 files changed, 30 insertions(+), 15 deletions(-)

diff --git a/meta/classes/grub-efi.bbclass b/meta/classes/grub-efi.bbclass
index c6f5d4e..c07e4a1 100644
--- a/meta/classes/grub-efi.bbclass
+++ b/meta/classes/grub-efi.bbclass
@@ -9,6 +9,7 @@
  # External variables
  # ${INITRD} - indicates a filesystem image to use as an initrd (optional)
  # ${ROOTFS} - indicates a filesystem image to include as the root filesystem 
(optional)
+# ${GRUB_GFXSERIAL} - set this to 1 to have graphics and serial in the boot 
menu
  # ${LABELS} - a list of targets for the automatic config
  # ${APPEND} - an override list of append strings for each label
  # ${GRUB_OPTS} - additional options to add to the config, ';' delimited # 
(optional)
@@ -16,6 +17,7 @@

  do_bootimg[depends] += "grub-efi-${TRANSLATED_TARGET_ARCH}-native:do_deploy"

+GRUB_SERIAL ?= "console=ttyS0,115200"
  GRUBCFG = "${S}/grub.cfg"
  GRUB_TIMEOUT ?= "10"
  #FIXME: build this from the machine config
@@ -55,6 +57,8 @@ python build_grub_cfg() {
  bb.error("WORKDIR not defined, unable to package")
  return

+gfxserial = d.getVar('GRUB_GFXSERIAL', True) or ""
+
  labels = d.getVar('LABELS', True)
  if not labels:
  bb.debug(1, "LABELS not defined, nothing to do")
@@ -88,6 +92,12 @@ python build_grub_cfg() {
  else:
  cfgfile.write('timeout=50\n')

+if gfxserial == "1":
+btypes = [ [ " graphics console", "console=tty0" ],
+[ " serial console", d.getVar('GRUB_SERIAL', True) or "" ] ]
+else:
+btypes = [ [ "", "" ] ]
+
  for label in labels.split():
  localdata = d.createCopy()

@@ -95,24 +105,27 @@ python build_grub_cfg() {
  if not overrides:
  raise bb.build.FuncFailed('OVERRIDES not defined')

-localdata.setVar('OVERRIDES', label + ':' + overrides)
-bb.data.update_data(localdata)
+for btype in btypes:
+localdata.setVar('OVERRIDES', label + ':' + overrides)
+bb.data.update_data(localdata)

-cfgfile.write('\nmenuentry \'%s\'{\n' % (label))
-if label == "install":
-label = "install-efi"
-cfgfile.write('linux /vmlinuz LABEL=%s' % (label))
+cfgfile.write('\nmenuentry \'%s%s\'{\n' % (label, btype[0]))
+lb = label
+if label == "install":
+lb = "install-efi"
+cfgfile.write('linux /vmlinuz LABEL=%s' % (lb))

-append = localdata.getVar('APPEND', True)
-initrd = localdata.getVar('INITRD', True)
+append = localdata.getVar('APPEND', True)
+initrd = localdata.getVar('INITRD', True)

-if append:
-cfgfile.write('%s' % (append))
-cfgfile.write('\n')
+if append:
+cfgfile.write('%s' % (append))
+cfgfile.write(' %s' % btype[1])
+cfgfile.write('\n')

-if initrd:
-cfgfile.write('initrd /initrd')
-cfgfile.write('\n}\n')
+if initrd:
+cfgfile.write('initrd /initrd')
+cfgfile.write('\n}\n')

  cfgfile.close()
  }
diff --git a/meta/conf/machine/qemux86-64.conf 
b/meta/conf/machine/qemux86-64.conf
index c572225..6f68410 100644
--- a/meta/conf/machine/qemux86-64.conf
+++ b/meta/conf/machine/qemux86-64.conf
@@ -21,6 +21,6 @@ XSERVER = "xserver-xorg \
 xf86-input-evdev \
 xf86-video-vmware"

-MACHINE_FEATURES += "x86"
+MACHINE_FEATURES += "x86 efi"

  MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "v86d"
diff --git a/meta/conf/machine/qemux86.conf b/meta/conf/machine/qemux86.conf
index 94ee573..57a9a50 100644
--- a/meta/conf/machine/qemux86.conf
+++ b/meta/conf/machine/qemux86.conf
@@ -22,5 +22,7 @@ XSERVER = "xserver-xorg \
 xf86-video-vmware"

  MACHINE_FEATURES += "x86"
+MACHINE_FEATURES += "efi"
+#MACHINE_FEATURES += "pcbios"

Did you intend to keep the commented out like vs what you did above in 
x86-64?



  MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "v86d"



Will this affect the genericx86* also?

Sau!

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] bitbake.conf: include machine name in DEPLOY_DIR_IMAGE

[Flanagan, Elizabeth]

This will need a LAYERVERSION_core bump for autobuilder compatibility.

On Thu, Sep 12, 2013 at 4:04 AM, Paul Eggleton
 wrote:
> This allows a clean seperation between image outputs from different
> machines, and makes it possible to have convenience symlinks to make
> the output ready to deploy.
>
> This did require some surgery in runqemu; if explicit paths to the image
> and kernel are not supplied then DEPLOY_DIR_IMAGE needs to be determined
> from bitbake or set in the environment. However the script does try to
> avoid requiring it unless it really is needed. Corresponding changes
> were made in the automated testing code as well.
>
> Based on an RFC patch by Koen Kooi 
>
> Signed-off-by: Paul Eggleton 
> ---
>  meta/classes/testimage.bbclass|  1 +
>  meta/conf/bitbake.conf|  2 +-
>  meta/lib/oeqa/utils/qemurunner.py |  8 +-
>  scripts/runqemu   | 56 
> +++
>  4 files changed, 48 insertions(+), 19 deletions(-)
>
> diff --git a/meta/classes/testimage.bbclass b/meta/classes/testimage.bbclass
> index 4eef0be..c83906d 100644
> --- a/meta/classes/testimage.bbclass
> +++ b/meta/classes/testimage.bbclass
> @@ -122,6 +122,7 @@ def testimage_main(d):
>
>  qemu = QemuRunner(machine, rootfs)
>  qemu.tmpdir = d.getVar("TMPDIR", True)
> +qemu.deploy_dir_image = d.getVar("DEPLOY_DIR_IMAGE", True)
>  qemu.display = d.getVar("BB_ORIGENV", False).getVar("DISPLAY", True)
>  qemu.logfile = os.path.join(testdir, "qemu_boot_log.%s" % 
> d.getVar('DATETIME', True))
>  try:
> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> index 2d19d86..0e1a9e2 100644
> --- a/meta/conf/bitbake.conf
> +++ b/meta/conf/bitbake.conf
> @@ -379,7 +379,7 @@ DEPLOY_DIR_TAR = "${DEPLOY_DIR}/tar"
>  DEPLOY_DIR_IPK = "${DEPLOY_DIR}/ipk"
>  DEPLOY_DIR_RPM = "${DEPLOY_DIR}/rpm"
>  DEPLOY_DIR_DEB = "${DEPLOY_DIR}/deb"
> -DEPLOY_DIR_IMAGE ?= "${DEPLOY_DIR}/images"
> +DEPLOY_DIR_IMAGE ?= "${DEPLOY_DIR}/images/${MACHINE}"
>  DEPLOY_DIR_TOOLS = "${DEPLOY_DIR}/tools"
>
>  PKGDATA_DIR = "${TMPDIR}/pkgdata/${MULTIMACH_TARGET_SYS}"
> diff --git a/meta/lib/oeqa/utils/qemurunner.py 
> b/meta/lib/oeqa/utils/qemurunner.py
> index b5c757a..d362ede 100644
> --- a/meta/lib/oeqa/utils/qemurunner.py
> +++ b/meta/lib/oeqa/utils/qemurunner.py
> @@ -16,7 +16,7 @@ import bb
>
>  class QemuRunner:
>
> -def __init__(self, machine, rootfs, display = None, tmpdir = None, 
> logfile = None, boottime = 400, runqemutime = 60):
> +def __init__(self, machine, rootfs, display = None, tmpdir = None, 
> deploy_dir_image = None, logfile = None, boottime = 400, runqemutime = 60):
>  # Popen object
>  self.runqemu = None
>
> @@ -28,6 +28,7 @@ class QemuRunner:
>
>  self.display = display
>  self.tmpdir = tmpdir
> +self.deploy_dir_image = deploy_dir_image
>  self.logfile = logfile
>  self.boottime = boottime
>  self.runqemutime = runqemutime
> @@ -71,6 +72,11 @@ class QemuRunner:
>  return False
>  else:
>  os.environ["OE_TMPDIR"] = self.tmpdir
> +if not os.path.exists(self.deploy_dir_image):
> +bb.error("Invalid DEPLOY_DIR_IMAGE path %s" % 
> self.deploy_dir_image)
> +return False
> +else:
> +os.environ["DEPLOY_DIR_IMAGE"] = self.deploy_dir_image
>
>  self.qemuparams = 'bootparams="console=tty1 console=ttyS0,115200n8" 
> qemuparams="-serial tcp:127.0.0.1:%s"' % self.serverport
>  if qemuparams:
> diff --git a/scripts/runqemu b/scripts/runqemu
> index b496785..efab1a2 100755
> --- a/scripts/runqemu
> +++ b/scripts/runqemu
> @@ -321,9 +321,17 @@ AKITA_DEFAULT_FSTYPE=jffs2
>  SPITZ_DEFAULT_KERNEL=zImage-spitz.bin
>  SPITZ_DEFAULT_FSTYPE=ext3
>
> -setup_tmpdir() {
> -if [ -z "$OE_TMPDIR" ]; then
> -# Try to get OE_TMPDIR from bitbake
> +setup_path_vars() {
> +if [ -z "$OE_TMPDIR" ] ; then
> +PATHS_REQUIRED=true
> +elif [ "$1" = "1" -a -z "$DEPLOY_DIR_IMAGE" ] ; then
> +PATHS_REQUIRED=true
> +else
> +PATHS_REQUIRED=false
> +fi
> +
> +if [ "$PATHS_REQUIRED" = "true" ]; then
> +# Try to get the variable values from bitbake
>  type -P bitbake &>/dev/null || {
>  echo "In order for this script to dynamically infer paths";
>  echo "to kernels or filesystem images, you either need";
> @@ -331,21 +339,35 @@ setup_tmpdir() {
>  echo "before running this script" >&2;
>  exit 1; }
>
> -# We have bitbake in PATH, get OE_TMPDIR from bitbake
> -OE_TMPDIR=`MACHINE=$MACHINE bitbake -e | grep ^TMPDIR=\" | cut -d 
> '=' -f2 | cut -d '"' -f2`
> +# We have bitbake in PATH, get the variable values from bitbake
> +BITBAKE_ENV_TMPFILE=`mktemp runqemu.XX`
> +if [ "$?" != "0" ] ; then
> +echo "Error: mktemp failed for bitbake environment output"
> +e

Re: [OE-core] [PATCH 0/2] make runlevel to return correct value

[Saul Wold]

On 09/11/2013 05:08 PM, Rongqing Li wrote:

ping...

You replied to your patch question if it was right, therefore I put this 
off expecting an updated patchset.


Or are you asking about 2/2?

Sau!


-Roy

On 09/04/2013 02:56 PM, rongqing...@windriver.com wrote:

From: "Roy.Li" 

The following changes since commit
8c272641ef3e8410f331ca4133d28dea8f36e4f4:

   lib/oeqa/runtime: smart: serve repo on host ip only and increase
timeout (2013-09-03 19:57:31 +0100)

are available in the git repository at:

   git://git.pokylinux.org/poky-contrib roy/systemd-1
   http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=roy/systemd-1

Roy.Li (2):
   systemd-compat-units: do not create runlevel command
   systemd: link runlevel from systemctl

  meta/recipes-core/systemd/systemd-compat-units.bb |5 -
  meta/recipes-core/systemd/systemd_206.bb  |6 +-
  2 files changed, 5 insertions(+), 6 deletions(-)




___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] image/populate_sdk: Ensure symlinks in target sysroot are relative

[Hans Beckérus]

On Thu, Sep 12, 2013 at 10:29 AM, Hans Beckérus  wrote:
> On Thu, Sep 12, 2013 at 10:02 AM, Richard Purdie
>  wrote:
>> On Thu, 2013-09-12 at 09:48 +0200, Hans Beckérus wrote:
>>> I have a slight problem with this patch. The new
>>> sysroot-relativelinks.py does not obtain the proper access protection
>>> bits!?
>>> Which results in the following error when packaging the SDK
>>>
>>> /home/poky/build/tmp/work/zynq_zc706-poky-linux-gnueabi/rootfs-default/1.0-r0/temp/run.populate_sdk_image.20803:
>>> line 496: /home/poky/scripts/sysroot-relativelinks.py: Permission
>>> denied
>>>
>>> [home/poky]: ls -l scripts/sysroot-relativelinks.py
>>> -rw-rw-r-- 1  poky poky 959 Sep 12 09:38 scripts/sysroot-relativelinks.py
>>>
>>> The execution bit is missing!?
>>>
>>> I can of course apply the execution bit manually, but what may cause
>>> the patch to not set the bits properly in my scripts folder for new
>>> files? Please advise.
>>
>> I checked the poky and oe-core trees and they have a+x:
>>
>> http://git.yoctoproject.org/cgit.cgi/poky/tree/scripts
>> http://git.openembedded.org/openembedded-core/tree/scripts
>>
>> so I'm a bit puzzled. How did you update your tree?
>>
> All the other scripts in the scripts folder has a+x, it is only the
> new .py file added by your patch that does not obtain it in my local
> tree.
>
As Richard so correctly pointed out to me, this is expected when I use
'patch' to bring it in :(
I must learn my lesson and start using 'git am' instead.

Thanks.
Hans

>> Cheers,
>>
>> Richard
>>
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] sstate.bbclass: fix parallel building issue

[Richard Purdie]

On Tue, 2013-08-13 at 16:20 +0800, rongqing...@windriver.com wrote:
> From: "Roy.Li" 
> 
> sstate_package creates hardlink from sysroot to SSTATE_BUILDDIR, then
> sstate_create_package will store SSTATE_BUILDDIR into a archive file by
> tar, but once other packages install the same file into sysroot, the
> creating the archive file will fail with below error:
> 
> DEBUG: Executing shell function sstate_create_package
> tar: x86_64-linux/usr/share/aclocal/xorg-macros.m4: file changed as we 
> read it
> 
> This kind of error is harmless, use --ignore-failed-read to ignore it.
> 
> Signed-off-by: Roy.Li 


I've dug into this issue a bit and having looked a the code in tar for
this warning, I believe this is the right fix.

Throughout the system we now hardlink files together and the timestamps
of the files can change when the number of hardlinks is changed so its
possible to race against various parts of the system. The aclocal-copy
is the most frequently used so we hit it there easiest.

So I'm now in favour of taking this patch. We could improve aclocal but
that is really a separate issue.

Cheers,

Richard

> ---
>  meta/classes/sstate.bbclass |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
> index c1ca54b..3e2fedd 100644
> --- a/meta/classes/sstate.bbclass
> +++ b/meta/classes/sstate.bbclass
> @@ -565,7 +565,7 @@ sstate_create_package () {
>   TFILE=`mktemp ${SSTATE_PKG}.`
>   # Need to handle empty directories
>   if [ "$(ls -A)" ]; then
> - tar -czf $TFILE *
> + tar --ignore-failed-read -czf $TFILE *
>   else
>   tar -cz --file=$TFILE --files-from=/dev/null
>   fi


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH][V2] xf86-video-vmware: disable VMWGFX

[Ross Burton]

Our Mesa doesn't yet ship the XA Gallium state tracker that the VMWGFX
sub-driver needs, so just disable vmwgfx.

Also remove a spurious xvmc dependency.

Signed-off-by: Ross Burton 
---
 .../xf86-video-vmware/vmwgfx-option.patch  |   72 
 .../xorg-driver/xf86-video-vmware_13.0.1.bb|7 +-
 2 files changed, 77 insertions(+), 2 deletions(-)
 create mode 100644 
meta/recipes-graphics/xorg-driver/xf86-video-vmware/vmwgfx-option.patch

diff --git 
a/meta/recipes-graphics/xorg-driver/xf86-video-vmware/vmwgfx-option.patch 
b/meta/recipes-graphics/xorg-driver/xf86-video-vmware/vmwgfx-option.patch
new file mode 100644
index 000..4b3a309
--- /dev/null
+++ b/meta/recipes-graphics/xorg-driver/xf86-video-vmware/vmwgfx-option.patch
@@ -0,0 +1,72 @@
+Upstream-Status: Submitted 
(http://lists.x.org/archives/xorg-devel/2013-September/037762.html)
+Signed-off-by: Ross Burton 
+
+From 5ec0aae666feb88d01256cdebbf94a6b373bf4c4 Mon Sep 17 00:00:00 2001
+From: Ross Burton 
+Date: Wed, 11 Sep 2013 21:40:44 +0100
+Subject: [PATCH] build: add explicit option to enable/disable VMWGFX
+
+Signed-off-by: Ross Burton 
+---
+ configure.ac |   31 ++-
+ 1 file changed, 14 insertions(+), 17 deletions(-)
+
+diff --git a/configure.ac b/configure.ac
+index 0631bcc..3e14abd 100644
+--- a/configure.ac
 b/configure.ac
+@@ -85,11 +85,6 @@ PKG_CHECK_EXISTS([xorg-server >= 1.4.99],
+  [AC_DEFINE([HAVE_XORG_SERVER_1_5_0], 1,
+  [Has version 1.5.0 or greater of the Xserver])])
+ 
+-PKG_CHECK_EXISTS([xorg-server >= 1.7.0],
+- [AC_DEFINE([HAVE_XORG_SERVER_1_7_0], 1,
+- [Has version 1.7.0 or greater of the Xserver])
+-   BUILD_VMWGFX=yes],[BUILD_VMWGFX=no])
+-
+ PKG_CHECK_EXISTS([xorg-server >= 1.12.0],
+  [AC_DEFINE([HAVE_XORG_SERVER_1_12_0], 1,
+  [Has version 1.12.0 or greater of the Xserver])])
+@@ -114,25 +109,27 @@ AM_CONDITIONAL(XSERVER_LIBPCIACCESS, test 
"x$XSERVER_LIBPCIACCESS" = xyes)
+ 
+ AC_SUBST([moduledir])
+ 
+-if test x$BUILD_VMWGFX = xyes; then
+-  PKG_CHECK_MODULES([LIBDRM], [libdrm],[],[BUILD_VMWGFX=no])
+-fi
+-if test x$BUILD_VMWGFX = xyes; then
+-  PKG_CHECK_MODULES([XATRACKER], [xatracker >= 
0.4.0],[],[BUILD_VMWGFX=no])
+-fi
+-
+ DRIVER_NAME=vmware
+ AC_SUBST([DRIVER_NAME])
+ 
++AC_ARG_ENABLE(vmwgfx,
++  AS_HELP_STRING([--disable-vmwgfx],
++ [Disable vmwgfx driver (KMS/3D) (default: 
enabled)]),
++ [VMWGFX="$enableval"], [VMWGFX="yes"])
++
+ AC_MSG_CHECKING([whether to build Kernel Mode Setting and 3D])
+-if test x$BUILD_VMWGFX = xyes; then
+-  AC_MSG_RESULT([yes])
++if test "x$VMWGFX" = xyes; then
++AC_MSG_RESULT([yes])
++PKG_CHECK_EXISTS([xorg-server >= 1.7.0],
++ [AC_DEFINE([HAVE_XORG_SERVER_1_7_0], 1,
++ [Has version 1.7.0 or greater of the Xserver])])
++PKG_CHECK_MODULES([LIBDRM], [libdrm])
++PKG_CHECK_MODULES([XATRACKER], [xatracker >= 0.4.0])
+ AC_DEFINE([BUILD_VMWGFX], 1, [Building the vmwgfx driver path])
+ else
+-  AC_MSG_RESULT([no])
++AC_MSG_RESULT([no])
+ fi
+-
+-AM_CONDITIONAL(BUILD_VMWGFX, test "x$BUILD_VMWGFX" = xyes)
++AM_CONDITIONAL(BUILD_VMWGFX, test "x$VMWGFX" = xyes)
+ 
+ AC_CONFIG_FILES([
+ Makefile
+-- 
+1.7.10.4
+
diff --git a/meta/recipes-graphics/xorg-driver/xf86-video-vmware_13.0.1.bb 
b/meta/recipes-graphics/xorg-driver/xf86-video-vmware_13.0.1.bb
index 0d8c8d2..7b48e0c 100644
--- a/meta/recipes-graphics/xorg-driver/xf86-video-vmware_13.0.1.bb
+++ b/meta/recipes-graphics/xorg-driver/xf86-video-vmware_13.0.1.bb
@@ -6,10 +6,13 @@ DESCRIPTION = "vmware is an Xorg driver for VMware virtual 
video cards."
 
 LIC_FILES_CHKSUM = "file://COPYING;md5=5fcd7d437a959a15fbee8707747c6b53"
 
-DEPENDS += "virtual/libx11 libxvmc xineramaproto libpciaccess \
-${@base_contains('DISTRO_FEATURES', 'opengl', 'drm virtual/libgl', 
'', d)}"
+DEPENDS += "virtual/libx11 xineramaproto videoproto libpciaccess"
+
+SRC_URI += "file://vmwgfx-option.patch"
 
 SRC_URI[md5sum] = "b08e0195ebf3f88a82129322cb93da08"
 SRC_URI[sha256sum] = 
"802dda415c22412edad6c3df44fe18a06e91d0f8456d9a58bac0d340fdf8fe3d"
 
 COMPATIBLE_HOST = '(i.86.*-linux|x86_64.*-linux)'
+
+EXTRA_OECONF += "--disable-vmwgfx"
-- 
1.7.10.4

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] bluez4/5: Add EXCLUDE_FROM_WORLD = 1

[Richard Purdie]

On Thu, 2013-09-12 at 10:29 +0100, Paul Eggleton wrote:
> On Wednesday 11 September 2013 14:38:01 Saul Wold wrote:
> > We can't build both recipes in the world build as there is a collision of
> > package name and PR values. Specificly the libasound-module-bluez which is
> > the same in both goes backwards from r5 (bluez4) -> r0 (bluez5) and the
> > subpackage_metadata check fails:
> > 
> > ERROR: Recipe lib32-bluez5 is trying to change PR from 'r0' to 'r5'. This
> > will cause do_package_write_* failures since the incorrect data will be
> > used and they will be unable to find the right workdir.
> > 
> > [YOCTO #5165]
> > 
> > Signed-off-by: Saul Wold 
> > ---
> >  meta/recipes-connectivity/bluez/bluez4.inc  | 1 +
> >  meta/recipes-connectivity/bluez5/bluez5.inc | 2 ++
> >  2 files changed, 3 insertions(+)
> > 
> > diff --git a/meta/recipes-connectivity/bluez/bluez4.inc
> > b/meta/recipes-connectivity/bluez/bluez4.inc index b540622..e4f6834 100644
> > --- a/meta/recipes-connectivity/bluez/bluez4.inc
> > +++ b/meta/recipes-connectivity/bluez/bluez4.inc
> > @@ -43,3 +43,4 @@ EXTRA_OECONF = "\
> >--with-udevrulesdir=`pkg-config --variable=udevdir udev`/rules.d \
> >  "
> > 
> > +EXCLUDE_FROM_WORLD = "1"
> > diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc
> > b/meta/recipes-connectivity/bluez5/bluez5.inc index e5cb9e8..2e25d86 100644
> > --- a/meta/recipes-connectivity/bluez5/bluez5.inc
> > +++ b/meta/recipes-connectivity/bluez5/bluez5.inc
> > @@ -82,3 +82,5 @@ FILES_${PN}-dbg += "\
> >  RDEPENDS_${PN}-testtools += "python python-dbus python-pygobject"
> > 
> >  SYSTEMD_SERVICE_${PN} = "bluetooth.service"
> > +
> > +EXCLUDE_FROM_WORLD = "1"
> 
> Surely we don't need to exclude both from world, just one of them?

This way the right one gets selected by the dependency trees. If you do
it the other way, we'd have to revisit the problem and anyone choosing
an alternative would possibly end up with build issues. 

Cheers,

Richard

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] bitbake.conf: include machine name in DEPLOY_DIR_IMAGE

[Martin Jansa]

On Thu, Sep 12, 2013 at 12:04:52PM +0100, Paul Eggleton wrote:
> This allows a clean seperation between image outputs from different
> machines, and makes it possible to have convenience symlinks to make
> the output ready to deploy.
> 
> This did require some surgery in runqemu; if explicit paths to the image
> and kernel are not supplied then DEPLOY_DIR_IMAGE needs to be determined
> from bitbake or set in the environment. However the script does try to
> avoid requiring it unless it really is needed. Corresponding changes
> were made in the automated testing code as well.
> 
> Based on an RFC patch by Koen Kooi 

I use this layout for long time, it's great to see runqemu/qemurunner
getting more robust to support such layout.

Acked-by: Martin Jansa 

> Signed-off-by: Paul Eggleton 
> ---
>  meta/classes/testimage.bbclass|  1 +
>  meta/conf/bitbake.conf|  2 +-
>  meta/lib/oeqa/utils/qemurunner.py |  8 +-
>  scripts/runqemu   | 56 
> +++
>  4 files changed, 48 insertions(+), 19 deletions(-)
> 
> diff --git a/meta/classes/testimage.bbclass b/meta/classes/testimage.bbclass
> index 4eef0be..c83906d 100644
> --- a/meta/classes/testimage.bbclass
> +++ b/meta/classes/testimage.bbclass
> @@ -122,6 +122,7 @@ def testimage_main(d):
>  
>  qemu = QemuRunner(machine, rootfs)
>  qemu.tmpdir = d.getVar("TMPDIR", True)
> +qemu.deploy_dir_image = d.getVar("DEPLOY_DIR_IMAGE", True)
>  qemu.display = d.getVar("BB_ORIGENV", False).getVar("DISPLAY", True)
>  qemu.logfile = os.path.join(testdir, "qemu_boot_log.%s" % 
> d.getVar('DATETIME', True))
>  try:
> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> index 2d19d86..0e1a9e2 100644
> --- a/meta/conf/bitbake.conf
> +++ b/meta/conf/bitbake.conf
> @@ -379,7 +379,7 @@ DEPLOY_DIR_TAR = "${DEPLOY_DIR}/tar"
>  DEPLOY_DIR_IPK = "${DEPLOY_DIR}/ipk"
>  DEPLOY_DIR_RPM = "${DEPLOY_DIR}/rpm"
>  DEPLOY_DIR_DEB = "${DEPLOY_DIR}/deb"
> -DEPLOY_DIR_IMAGE ?= "${DEPLOY_DIR}/images"
> +DEPLOY_DIR_IMAGE ?= "${DEPLOY_DIR}/images/${MACHINE}"
>  DEPLOY_DIR_TOOLS = "${DEPLOY_DIR}/tools"
>  
>  PKGDATA_DIR = "${TMPDIR}/pkgdata/${MULTIMACH_TARGET_SYS}"
> diff --git a/meta/lib/oeqa/utils/qemurunner.py 
> b/meta/lib/oeqa/utils/qemurunner.py
> index b5c757a..d362ede 100644
> --- a/meta/lib/oeqa/utils/qemurunner.py
> +++ b/meta/lib/oeqa/utils/qemurunner.py
> @@ -16,7 +16,7 @@ import bb
>  
>  class QemuRunner:
>  
> -def __init__(self, machine, rootfs, display = None, tmpdir = None, 
> logfile = None, boottime = 400, runqemutime = 60):
> +def __init__(self, machine, rootfs, display = None, tmpdir = None, 
> deploy_dir_image = None, logfile = None, boottime = 400, runqemutime = 60):
>  # Popen object
>  self.runqemu = None
>  
> @@ -28,6 +28,7 @@ class QemuRunner:
>  
>  self.display = display
>  self.tmpdir = tmpdir
> +self.deploy_dir_image = deploy_dir_image
>  self.logfile = logfile
>  self.boottime = boottime
>  self.runqemutime = runqemutime
> @@ -71,6 +72,11 @@ class QemuRunner:
>  return False
>  else:
>  os.environ["OE_TMPDIR"] = self.tmpdir
> +if not os.path.exists(self.deploy_dir_image):
> +bb.error("Invalid DEPLOY_DIR_IMAGE path %s" % 
> self.deploy_dir_image)
> +return False
> +else:
> +os.environ["DEPLOY_DIR_IMAGE"] = self.deploy_dir_image
>  
>  self.qemuparams = 'bootparams="console=tty1 console=ttyS0,115200n8" 
> qemuparams="-serial tcp:127.0.0.1:%s"' % self.serverport
>  if qemuparams:
> diff --git a/scripts/runqemu b/scripts/runqemu
> index b496785..efab1a2 100755
> --- a/scripts/runqemu
> +++ b/scripts/runqemu
> @@ -321,9 +321,17 @@ AKITA_DEFAULT_FSTYPE=jffs2
>  SPITZ_DEFAULT_KERNEL=zImage-spitz.bin
>  SPITZ_DEFAULT_FSTYPE=ext3
>  
> -setup_tmpdir() {
> -if [ -z "$OE_TMPDIR" ]; then
> -# Try to get OE_TMPDIR from bitbake
> +setup_path_vars() {
> +if [ -z "$OE_TMPDIR" ] ; then
> +PATHS_REQUIRED=true
> +elif [ "$1" = "1" -a -z "$DEPLOY_DIR_IMAGE" ] ; then
> +PATHS_REQUIRED=true
> +else
> +PATHS_REQUIRED=false
> +fi
> +
> +if [ "$PATHS_REQUIRED" = "true" ]; then
> +# Try to get the variable values from bitbake
>  type -P bitbake &>/dev/null || {
>  echo "In order for this script to dynamically infer paths";
>  echo "to kernels or filesystem images, you either need";
> @@ -331,21 +339,35 @@ setup_tmpdir() {
>  echo "before running this script" >&2;
>  exit 1; }
>  
> -# We have bitbake in PATH, get OE_TMPDIR from bitbake
> -OE_TMPDIR=`MACHINE=$MACHINE bitbake -e | grep ^TMPDIR=\" | cut -d 
> '=' -f2 | cut -d '"' -f2`
> +# We have bitbake in PATH, get the variable values from bitbake
> +BITBAKE_ENV_TMPFILE=`mktemp runqemu.XX`
> +if [ "$?" != "0" ] ;

Re: [OE-core] [PATCH 1/1] update-rc.d.bbclass: change RRECOMMENDS to RDEPENDS

[Martin Jansa]

On Thu, Sep 12, 2013 at 07:18:12PM +0800, ChenQi wrote:
> On 09/12/2013 06:25 PM, Martin Jansa wrote:
> > On Thu, Sep 12, 2013 at 05:43:55PM +0800, qi.c...@windriver.com wrote:
> >> From: Chen Qi 
> >>
> >> If a package inherits update-rc.d.bbclass, it actually needs it to
> >> update the symlinks under /etc/rc?.d/ directories. This is a runtime
> >> dependency. For example, if we try to upgrade the dropbear on target,
> >> its postinst process will need the update-rc.d utility available,
> >> otherwise, the upgrade process will fail.
> >>
> >> Besides, if we only recommend update-rc.d, the do_rootfs process will
> >> fail once NO_RRECOMMENDATIONS is enabled. Because in OE, we try to do
> >> the postinsts at rootfs time.
> > IIRC it was changed to allow systemd images to be built completely
> > without update-rc.d (with BAD_RECOMMENDATIONS += "update-rc.d") and it's
> > IMHO still valid use-case as update-rc.d is inherited even when systemd
> > is used.
> >
> 
> Now that the 'rm_sysvinit_initdir' function has been added to the 
> systemd.bbclass, I think we can safely use RDEPENDS here. Because
> 1) If the /etc/init is removed, update-rc.d command in postinst has no 
> real effect.
> 2) If the /etc/init is not removed, that means symlinks under 
> /etc/rc?.d/ should be set up.
> 
> So I think there's no negative effect if update-rc.d is installed in 
> case of a systemd system.
> 
> Also, I don't think adding update-rc.d to BAD_RECOMMENDATIONS is a good 
> idea.
> For example, we have a systemd based image running and we are installing 
> a new package to that image. That package has an init script but no 
> corresponding service file. If we only recommend update-rc.d and it's in 
> BAD_RECOMMENDATIONS, the install process will fail. This is not what 
> user might expect.
> 
> So I'd like to suggest that we change it back to RDEPENDS.

commit 2c403979c03898c679c5a1e1092aec784dbeb77c
Author: Ross Burton 
Date:   Tue Mar 5 11:57:00 2013 +

update-rcd: drop depends to recommends, check for update-rcd in scripts

This class is still checking if update-rc.d is installed before using
it, so nothing should fail terribly if image developer decides that he
want's image without any sysvinit related stuff.

If you want image which supports both you can add runtime dependency on
update-rc.d somewhere else - it doesn't need to be pulled by every
recipe which inherits update-rc.d bbclass.

> Best Regards,
> Chen Qi
> 
> >> This patch fixes this problem by changing the RRECOMMENDS to RDEPENDS
> >> to let the packages actually rdepend on update-rc.d.
> >>
> >> [YOCTO #5169]
> >>
> >> Signed-off-by: Chen Qi 
> >> ---
> >>   meta/classes/update-rc.d.bbclass |2 +-
> >>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/meta/classes/update-rc.d.bbclass 
> >> b/meta/classes/update-rc.d.bbclass
> >> index 5588569..3dee13a 100644
> >> --- a/meta/classes/update-rc.d.bbclass
> >> +++ b/meta/classes/update-rc.d.bbclass
> >> @@ -6,7 +6,7 @@ UPDATERCD_virtclass-cross = ""
> >>   UPDATERCD_class-native = ""
> >>   UPDATERCD_class-nativesdk = ""
> >>   
> >> -RRECOMMENDS_${UPDATERCPN}_append = " ${UPDATERCD}"
> >> +RDEPENDS_${UPDATERCPN}_append = " ${UPDATERCD}"
> >>   
> >>   INITSCRIPT_PARAMS ?= "defaults"
> >>   
> >> -- 
> >> 1.7.9.5
> >>
> >> ___
> >> Openembedded-core mailing list
> >> Openembedded-core@lists.openembedded.org
> >> http://lists.openembedded.org/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.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] kernel.bbclass: Need a method to install/update for bzImage

[Hongxu Jia]

On 09/12/2013 05:47 PM, Mike Looijmans wrote:
This change just assumes that all boot systems are alike. Just 
applying this patch "as is" will probably break a lot of embedded 
systems that have totally different ways of upgrading the kernel. Best 
scenario is that they'll waste time and space running scripts that 
will have no effect.


It should be possible - and more important: default - to NOT include 
these scripts, and use them only on targets they apply to. 
kernel.bbclass is in my opinion not the correct location.




Yes, we should add a on-off to decide whether the method should be used 
or not,

and set off by default.

But I could not find a better location to do this, almost all of targets 
in oe-core may

need this, do you have any suggestions?

Thanks,
Hongxu
Otherwise, should I add my kernel postinstall script that writes the 
kernel into an MTD block on an embedded target to this class as well? 
And a NAND version? And SD?


Mike.


On 09/12/2013 11:25 AM, Hongxu Jia wrote:
While installing a rpm to update kernel on a deployed target, it will 
update
the boot area and the boot menu with the kernel as the priority but 
allow

you to fall back to the original kernel as well.

- In pre-install script, it backs up original kernel to avoid 
confliction with

   new one.
- In post-install script, it updates the new kernel as the boot 
priority.


[YOCTO #4104]

Signed-off-by: Hongxu Jia 
---
  meta/classes/kernel.bbclass | 65 
+

  1 file changed, 65 insertions(+)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index e039dfc..f0dd679 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -263,7 +263,72 @@ ALLOW_EMPTY_kernel-image = "1"
  ALLOW_EMPTY_kernel-modules = "1"
  DESCRIPTION_kernel-modules = "Kernel modules meta package"

+pkg_preinst_kernel-image () {
+if [ -z "$D" ]; then
+# Parsing confliction
+[ -f /boot/grub/menu.list ] && grubcfg="/boot/grub/menu.list"
+[ -f /boot/grub/grub.cfg ] && grubcfg="/boot/grub/grub.cfg"
+if [ -n "$grubcfg" ]; then
+# Dereference symlink to avoid confliction with new 
kernel name.

+if grep -q "/${KERNEL_IMAGETYPE} root=" $grubcfg; then
+kimage=`realpath /boot/${KERNEL_IMAGETYPE}`;
+sed -i "s#${KERNEL_IMAGETYPE} root=#${kimage##*/} 
root=#" $grubcfg

+fi
+
+# Rename old kernel if it conflicts with new kernel name.
+if grep -q "/${KERNEL_IMAGETYPE}-${KERNEL_VERSION} 
root=" $grubcfg; then

+timestamp=`date +%s`
+ kimage="/boot/${KERNEL_IMAGETYPE}-${KERNEL_VERSION}-$timestamp-back"
+sed -i "s#${KERNEL_IMAGETYPE}-${KERNEL_VERSION} 
root=#${kimage##*/} root=#" $grubcfg

+mv /boot/${KERNEL_IMAGETYPE}-${KERNEL_VERSION} $kimage
+fi
+fi
+fi
+}
+
  pkg_postinst_kernel-image () {
+get_new_grub_cfg() {
+title="Update ${KERNEL_IMAGETYPE}-${KERNEL_VERSION}-${PV}"
+if [ -f /boot/grub/grub.cfg ]; then
+rootfs=`grep " *linux [^ ].* root=" /boot/grub/grub.cfg 
-m 1 | \
+ sed "s# *linux [^ ].* root=#linux 
/${KERNEL_IMAGETYPE}-${KERNEL_VERSION} root=#"`

+
+echo "menuentry \"$title\" {"
+echo "set root=(hd0,1)"
+echo "$rootfs"
+echo "}"
+elif [ -f /boot/grub/menu.list ] ; then
+rootfs=`grep "kernel [^ ].* root=" /boot/grub/menu.list 
-m 1 | \
+ sed "s#kernel [^ ].* root=#kernel 
/${KERNEL_IMAGETYPE}-${KERNEL_VERSION} root=#"`

+
+echo "default 0"
+echo "timeout 30"
+echo "title $title"
+echo "root  (hd0,0)"
+echo "$rootfs"
+fi
+}
+
+get_old_grub_cfg() {
+if [ -f /boot/grub/grub.cfg ]; then
+cat /boot/grub/grub.cfg
+elif [ -f /boot/grub/menu.list ] ; then
+cat /boot/grub/menu.list | sed -e '/^default/d' -e 
'/^timeout/d'

+fi
+}
+
+if [ -z "$D" ]; then
+[ -f /boot/grub/menu.list ] && grubcfg="/boot/grub/menu.list"
+[ -f /boot/grub/grub.cfg ] && grubcfg="/boot/grub/grub.cfg"
+if [ -n "$grubcfg" ]; then
+grubcfgtmp="$grubcfg.tmp"
+get_new_grub_cfg  > $grubcfgtmp
+get_old_grub_cfg >> $grubcfgtmp
+mv $grubcfgtmp $grubcfg
+echo "Caution! Update kernel may affect kernel-module!"
+fi
+fi
+
  update-alternatives --install 
/${KERNEL_IMAGEDEST}/${KERNEL_IMAGETYPE} ${KERNEL_IMAGETYPE} 
${KERNEL_IMAGETYPE}-${KERNEL_VERSION} ${KERNEL_PRIORITY} || true

  if [ ! -e "$D/lib/modules/${KERNEL_VERSION}" ]; then
  mkdir -p $D/lib/modules/${KERNEL_VERSION}





Met vriendelijke groet / kind regards,

Mike Looijmans

TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) – (0)499 - 

[OE-core] [PATCH] xf86-video-vmware: disable VMWGFX

[Ross Burton]

Our Mesa doesn't yet ship the XA Gallium state tracker that the VMWGFX
sub-driver needs, so just disable vmwgfx.

Also remove a spurious xvmc dependency.

Signed-off-by: Ross Burton 
---
 .../xf86-video-vmware/vmwgfx-option.patch  |   69 
 .../xorg-driver/xf86-video-vmware_13.0.1.bb|7 +-
 2 files changed, 74 insertions(+), 2 deletions(-)
 create mode 100644 
meta/recipes-graphics/xorg-driver/xf86-video-vmware/vmwgfx-option.patch

diff --git 
a/meta/recipes-graphics/xorg-driver/xf86-video-vmware/vmwgfx-option.patch 
b/meta/recipes-graphics/xorg-driver/xf86-video-vmware/vmwgfx-option.patch
new file mode 100644
index 000..9256449
--- /dev/null
+++ b/meta/recipes-graphics/xorg-driver/xf86-video-vmware/vmwgfx-option.patch
@@ -0,0 +1,69 @@
+From 5ec0aae666feb88d01256cdebbf94a6b373bf4c4 Mon Sep 17 00:00:00 2001
+From: Ross Burton 
+Date: Wed, 11 Sep 2013 21:40:44 +0100
+Subject: [PATCH] build: add explicit option to enable/disable VMWGFX
+
+Signed-off-by: Ross Burton 
+---
+ configure.ac |   31 ++-
+ 1 file changed, 14 insertions(+), 17 deletions(-)
+
+diff --git a/configure.ac b/configure.ac
+index 0631bcc..3e14abd 100644
+--- a/configure.ac
 b/configure.ac
+@@ -85,11 +85,6 @@ PKG_CHECK_EXISTS([xorg-server >= 1.4.99],
+  [AC_DEFINE([HAVE_XORG_SERVER_1_5_0], 1,
+  [Has version 1.5.0 or greater of the Xserver])])
+ 
+-PKG_CHECK_EXISTS([xorg-server >= 1.7.0],
+- [AC_DEFINE([HAVE_XORG_SERVER_1_7_0], 1,
+- [Has version 1.7.0 or greater of the Xserver])
+-   BUILD_VMWGFX=yes],[BUILD_VMWGFX=no])
+-
+ PKG_CHECK_EXISTS([xorg-server >= 1.12.0],
+  [AC_DEFINE([HAVE_XORG_SERVER_1_12_0], 1,
+  [Has version 1.12.0 or greater of the Xserver])])
+@@ -114,25 +109,27 @@ AM_CONDITIONAL(XSERVER_LIBPCIACCESS, test 
"x$XSERVER_LIBPCIACCESS" = xyes)
+ 
+ AC_SUBST([moduledir])
+ 
+-if test x$BUILD_VMWGFX = xyes; then
+-  PKG_CHECK_MODULES([LIBDRM], [libdrm],[],[BUILD_VMWGFX=no])
+-fi
+-if test x$BUILD_VMWGFX = xyes; then
+-  PKG_CHECK_MODULES([XATRACKER], [xatracker >= 
0.4.0],[],[BUILD_VMWGFX=no])
+-fi
+-
+ DRIVER_NAME=vmware
+ AC_SUBST([DRIVER_NAME])
+ 
++AC_ARG_ENABLE(vmwgfx,
++  AS_HELP_STRING([--disable-vmwgfx],
++ [Disable vmwgfx driver (KMS/3D) (default: 
enabled)]),
++ [VMWGFX="$enableval"], [VMWGFX="yes"])
++
+ AC_MSG_CHECKING([whether to build Kernel Mode Setting and 3D])
+-if test x$BUILD_VMWGFX = xyes; then
+-  AC_MSG_RESULT([yes])
++if test "x$VMWGFX" = xyes; then
++AC_MSG_RESULT([yes])
++PKG_CHECK_EXISTS([xorg-server >= 1.7.0],
++ [AC_DEFINE([HAVE_XORG_SERVER_1_7_0], 1,
++ [Has version 1.7.0 or greater of the Xserver])])
++PKG_CHECK_MODULES([LIBDRM], [libdrm])
++PKG_CHECK_MODULES([XATRACKER], [xatracker >= 0.4.0])
+ AC_DEFINE([BUILD_VMWGFX], 1, [Building the vmwgfx driver path])
+ else
+-  AC_MSG_RESULT([no])
++AC_MSG_RESULT([no])
+ fi
+-
+-AM_CONDITIONAL(BUILD_VMWGFX, test "x$BUILD_VMWGFX" = xyes)
++AM_CONDITIONAL(BUILD_VMWGFX, test "x$VMWGFX" = xyes)
+ 
+ AC_CONFIG_FILES([
+ Makefile
+-- 
+1.7.10.4
+
diff --git a/meta/recipes-graphics/xorg-driver/xf86-video-vmware_13.0.1.bb 
b/meta/recipes-graphics/xorg-driver/xf86-video-vmware_13.0.1.bb
index 0d8c8d2..7b48e0c 100644
--- a/meta/recipes-graphics/xorg-driver/xf86-video-vmware_13.0.1.bb
+++ b/meta/recipes-graphics/xorg-driver/xf86-video-vmware_13.0.1.bb
@@ -6,10 +6,13 @@ DESCRIPTION = "vmware is an Xorg driver for VMware virtual 
video cards."
 
 LIC_FILES_CHKSUM = "file://COPYING;md5=5fcd7d437a959a15fbee8707747c6b53"
 
-DEPENDS += "virtual/libx11 libxvmc xineramaproto libpciaccess \
-${@base_contains('DISTRO_FEATURES', 'opengl', 'drm virtual/libgl', 
'', d)}"
+DEPENDS += "virtual/libx11 xineramaproto videoproto libpciaccess"
+
+SRC_URI += "file://vmwgfx-option.patch"
 
 SRC_URI[md5sum] = "b08e0195ebf3f88a82129322cb93da08"
 SRC_URI[sha256sum] = 
"802dda415c22412edad6c3df44fe18a06e91d0f8456d9a58bac0d340fdf8fe3d"
 
 COMPATIBLE_HOST = '(i.86.*-linux|x86_64.*-linux)'
+
+EXTRA_OECONF += "--disable-vmwgfx"
-- 
1.7.10.4

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] update-rc.d.bbclass: change RRECOMMENDS to RDEPENDS

[ChenQi]

On 09/12/2013 06:25 PM, Martin Jansa wrote:

On Thu, Sep 12, 2013 at 05:43:55PM +0800, qi.c...@windriver.com wrote:

From: Chen Qi 

If a package inherits update-rc.d.bbclass, it actually needs it to
update the symlinks under /etc/rc?.d/ directories. This is a runtime
dependency. For example, if we try to upgrade the dropbear on target,
its postinst process will need the update-rc.d utility available,
otherwise, the upgrade process will fail.

Besides, if we only recommend update-rc.d, the do_rootfs process will
fail once NO_RRECOMMENDATIONS is enabled. Because in OE, we try to do
the postinsts at rootfs time.

IIRC it was changed to allow systemd images to be built completely
without update-rc.d (with BAD_RECOMMENDATIONS += "update-rc.d") and it's
IMHO still valid use-case as update-rc.d is inherited even when systemd
is used.



Now that the 'rm_sysvinit_initdir' function has been added to the 
systemd.bbclass, I think we can safely use RDEPENDS here. Because
1) If the /etc/init is removed, update-rc.d command in postinst has no 
real effect.
2) If the /etc/init is not removed, that means symlinks under 
/etc/rc?.d/ should be set up.


So I think there's no negative effect if update-rc.d is installed in 
case of a systemd system.


Also, I don't think adding update-rc.d to BAD_RECOMMENDATIONS is a good 
idea.
For example, we have a systemd based image running and we are installing 
a new package to that image. That package has an init script but no 
corresponding service file. If we only recommend update-rc.d and it's in 
BAD_RECOMMENDATIONS, the install process will fail. This is not what 
user might expect.


So I'd like to suggest that we change it back to RDEPENDS.

Best Regards,
Chen Qi


This patch fixes this problem by changing the RRECOMMENDS to RDEPENDS
to let the packages actually rdepend on update-rc.d.

[YOCTO #5169]

Signed-off-by: Chen Qi 
---
  meta/classes/update-rc.d.bbclass |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/update-rc.d.bbclass b/meta/classes/update-rc.d.bbclass
index 5588569..3dee13a 100644
--- a/meta/classes/update-rc.d.bbclass
+++ b/meta/classes/update-rc.d.bbclass
@@ -6,7 +6,7 @@ UPDATERCD_virtclass-cross = ""
  UPDATERCD_class-native = ""
  UPDATERCD_class-nativesdk = ""
  
-RRECOMMENDS_${UPDATERCPN}_append = " ${UPDATERCD}"

+RDEPENDS_${UPDATERCPN}_append = " ${UPDATERCD}"
  
  INITSCRIPT_PARAMS ?= "defaults"
  
--

1.7.9.5

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] bitbake.conf: include machine name in DEPLOY_DIR_IMAGE

[Paul Eggleton]

This allows a clean seperation between image outputs from different
machines, and makes it possible to have convenience symlinks to make
the output ready to deploy.

This did require some surgery in runqemu; if explicit paths to the image
and kernel are not supplied then DEPLOY_DIR_IMAGE needs to be determined
from bitbake or set in the environment. However the script does try to
avoid requiring it unless it really is needed. Corresponding changes
were made in the automated testing code as well.

Based on an RFC patch by Koen Kooi 

Signed-off-by: Paul Eggleton 
---
 meta/classes/testimage.bbclass|  1 +
 meta/conf/bitbake.conf|  2 +-
 meta/lib/oeqa/utils/qemurunner.py |  8 +-
 scripts/runqemu   | 56 +++
 4 files changed, 48 insertions(+), 19 deletions(-)

diff --git a/meta/classes/testimage.bbclass b/meta/classes/testimage.bbclass
index 4eef0be..c83906d 100644
--- a/meta/classes/testimage.bbclass
+++ b/meta/classes/testimage.bbclass
@@ -122,6 +122,7 @@ def testimage_main(d):
 
 qemu = QemuRunner(machine, rootfs)
 qemu.tmpdir = d.getVar("TMPDIR", True)
+qemu.deploy_dir_image = d.getVar("DEPLOY_DIR_IMAGE", True)
 qemu.display = d.getVar("BB_ORIGENV", False).getVar("DISPLAY", True)
 qemu.logfile = os.path.join(testdir, "qemu_boot_log.%s" % 
d.getVar('DATETIME', True))
 try:
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 2d19d86..0e1a9e2 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -379,7 +379,7 @@ DEPLOY_DIR_TAR = "${DEPLOY_DIR}/tar"
 DEPLOY_DIR_IPK = "${DEPLOY_DIR}/ipk"
 DEPLOY_DIR_RPM = "${DEPLOY_DIR}/rpm"
 DEPLOY_DIR_DEB = "${DEPLOY_DIR}/deb"
-DEPLOY_DIR_IMAGE ?= "${DEPLOY_DIR}/images"
+DEPLOY_DIR_IMAGE ?= "${DEPLOY_DIR}/images/${MACHINE}"
 DEPLOY_DIR_TOOLS = "${DEPLOY_DIR}/tools"
 
 PKGDATA_DIR = "${TMPDIR}/pkgdata/${MULTIMACH_TARGET_SYS}"
diff --git a/meta/lib/oeqa/utils/qemurunner.py 
b/meta/lib/oeqa/utils/qemurunner.py
index b5c757a..d362ede 100644
--- a/meta/lib/oeqa/utils/qemurunner.py
+++ b/meta/lib/oeqa/utils/qemurunner.py
@@ -16,7 +16,7 @@ import bb
 
 class QemuRunner:
 
-def __init__(self, machine, rootfs, display = None, tmpdir = None, logfile 
= None, boottime = 400, runqemutime = 60):
+def __init__(self, machine, rootfs, display = None, tmpdir = None, 
deploy_dir_image = None, logfile = None, boottime = 400, runqemutime = 60):
 # Popen object
 self.runqemu = None
 
@@ -28,6 +28,7 @@ class QemuRunner:
 
 self.display = display
 self.tmpdir = tmpdir
+self.deploy_dir_image = deploy_dir_image
 self.logfile = logfile
 self.boottime = boottime
 self.runqemutime = runqemutime
@@ -71,6 +72,11 @@ class QemuRunner:
 return False
 else:
 os.environ["OE_TMPDIR"] = self.tmpdir
+if not os.path.exists(self.deploy_dir_image):
+bb.error("Invalid DEPLOY_DIR_IMAGE path %s" % 
self.deploy_dir_image)
+return False
+else:
+os.environ["DEPLOY_DIR_IMAGE"] = self.deploy_dir_image
 
 self.qemuparams = 'bootparams="console=tty1 console=ttyS0,115200n8" 
qemuparams="-serial tcp:127.0.0.1:%s"' % self.serverport
 if qemuparams:
diff --git a/scripts/runqemu b/scripts/runqemu
index b496785..efab1a2 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -321,9 +321,17 @@ AKITA_DEFAULT_FSTYPE=jffs2
 SPITZ_DEFAULT_KERNEL=zImage-spitz.bin
 SPITZ_DEFAULT_FSTYPE=ext3
 
-setup_tmpdir() {
-if [ -z "$OE_TMPDIR" ]; then
-# Try to get OE_TMPDIR from bitbake
+setup_path_vars() {
+if [ -z "$OE_TMPDIR" ] ; then
+PATHS_REQUIRED=true
+elif [ "$1" = "1" -a -z "$DEPLOY_DIR_IMAGE" ] ; then
+PATHS_REQUIRED=true
+else
+PATHS_REQUIRED=false
+fi
+
+if [ "$PATHS_REQUIRED" = "true" ]; then
+# Try to get the variable values from bitbake
 type -P bitbake &>/dev/null || {
 echo "In order for this script to dynamically infer paths";
 echo "to kernels or filesystem images, you either need";
@@ -331,21 +339,35 @@ setup_tmpdir() {
 echo "before running this script" >&2;
 exit 1; }
 
-# We have bitbake in PATH, get OE_TMPDIR from bitbake
-OE_TMPDIR=`MACHINE=$MACHINE bitbake -e | grep ^TMPDIR=\" | cut -d '=' 
-f2 | cut -d '"' -f2`
+# We have bitbake in PATH, get the variable values from bitbake
+BITBAKE_ENV_TMPFILE=`mktemp runqemu.XX`
+if [ "$?" != "0" ] ; then
+echo "Error: mktemp failed for bitbake environment output"
+exit 1
+fi
+
+MACHINE=$MACHINE bitbake -e > $BITBAKE_ENV_TMPFILE
+if [ -z "$OE_TMPDIR" ] ; then
+OE_TMPDIR=`cat $BITBAKE_ENV_TMPFILE | sed -n 
's/^TMPDIR=\"\(.*\)\"/\1/p'`
+fi
+if [ -z "$DEPLOY_DIR_IMAGE" ] ; then
+DEPLOY_DIR_IMAGE=`cat $BITBAKE_ENV_TMPFILE | sed -n 
's/^DEPLOY_DIR_IMAG

Re: [OE-core] [PATCH 1/1] update-rc.d.bbclass: change RRECOMMENDS to RDEPENDS

[Martin Jansa]

On Thu, Sep 12, 2013 at 05:43:55PM +0800, qi.c...@windriver.com wrote:
> From: Chen Qi 
> 
> If a package inherits update-rc.d.bbclass, it actually needs it to
> update the symlinks under /etc/rc?.d/ directories. This is a runtime
> dependency. For example, if we try to upgrade the dropbear on target,
> its postinst process will need the update-rc.d utility available,
> otherwise, the upgrade process will fail.
> 
> Besides, if we only recommend update-rc.d, the do_rootfs process will
> fail once NO_RRECOMMENDATIONS is enabled. Because in OE, we try to do
> the postinsts at rootfs time.

IIRC it was changed to allow systemd images to be built completely
without update-rc.d (with BAD_RECOMMENDATIONS += "update-rc.d") and it's
IMHO still valid use-case as update-rc.d is inherited even when systemd
is used.

> 
> This patch fixes this problem by changing the RRECOMMENDS to RDEPENDS
> to let the packages actually rdepend on update-rc.d.
> 
> [YOCTO #5169]
> 
> Signed-off-by: Chen Qi 
> ---
>  meta/classes/update-rc.d.bbclass |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/classes/update-rc.d.bbclass 
> b/meta/classes/update-rc.d.bbclass
> index 5588569..3dee13a 100644
> --- a/meta/classes/update-rc.d.bbclass
> +++ b/meta/classes/update-rc.d.bbclass
> @@ -6,7 +6,7 @@ UPDATERCD_virtclass-cross = ""
>  UPDATERCD_class-native = ""
>  UPDATERCD_class-nativesdk = ""
>  
> -RRECOMMENDS_${UPDATERCPN}_append = " ${UPDATERCD}"
> +RDEPENDS_${UPDATERCPN}_append = " ${UPDATERCD}"
>  
>  INITSCRIPT_PARAMS ?= "defaults"
>  
> -- 
> 1.7.9.5
> 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/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.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] kernel.bbclass: Need a method to install/update for bzImage

[Mike Looijmans]

This change just assumes that all boot systems are alike. Just applying 
this patch "as is" will probably break a lot of embedded systems that 
have totally different ways of upgrading the kernel. Best scenario is 
that they'll waste time and space running scripts that will have no effect.


It should be possible - and more important: default - to NOT include 
these scripts, and use them only on targets they apply to. 
kernel.bbclass is in my opinion not the correct location.


Otherwise, should I add my kernel postinstall script that writes the 
kernel into an MTD block on an embedded target to this class as well? 
And a NAND version? And SD?


Mike.


On 09/12/2013 11:25 AM, Hongxu Jia wrote:

While installing a rpm to update kernel on a deployed target, it will update
the boot area and the boot menu with the kernel as the priority but allow
you to fall back to the original kernel as well.

- In pre-install script, it backs up original kernel to avoid confliction with
   new one.
- In post-install script, it updates the new kernel as the boot priority.

[YOCTO #4104]

Signed-off-by: Hongxu Jia 
---
  meta/classes/kernel.bbclass | 65 +
  1 file changed, 65 insertions(+)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index e039dfc..f0dd679 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -263,7 +263,72 @@ ALLOW_EMPTY_kernel-image = "1"
  ALLOW_EMPTY_kernel-modules = "1"
  DESCRIPTION_kernel-modules = "Kernel modules meta package"

+pkg_preinst_kernel-image () {
+   if [ -z "$D" ]; then
+   # Parsing confliction
+   [ -f /boot/grub/menu.list ] && grubcfg="/boot/grub/menu.list"
+   [ -f /boot/grub/grub.cfg ] && grubcfg="/boot/grub/grub.cfg"
+   if [ -n "$grubcfg" ]; then
+   # Dereference symlink to avoid confliction with new 
kernel name.
+   if grep -q "/${KERNEL_IMAGETYPE} root=" $grubcfg; then
+   kimage=`realpath /boot/${KERNEL_IMAGETYPE}`;
+   sed -i "s#${KERNEL_IMAGETYPE} root=#${kimage##*/} 
root=#" $grubcfg
+   fi
+
+   # Rename old kernel if it conflicts with new kernel 
name.
+   if grep -q "/${KERNEL_IMAGETYPE}-${KERNEL_VERSION} 
root=" $grubcfg; then
+   timestamp=`date +%s`
+   
kimage="/boot/${KERNEL_IMAGETYPE}-${KERNEL_VERSION}-$timestamp-back"
+   sed -i "s#${KERNEL_IMAGETYPE}-${KERNEL_VERSION} 
root=#${kimage##*/} root=#" $grubcfg
+   mv /boot/${KERNEL_IMAGETYPE}-${KERNEL_VERSION} 
$kimage
+   fi
+   fi
+   fi
+}
+
  pkg_postinst_kernel-image () {
+   get_new_grub_cfg() {
+   title="Update ${KERNEL_IMAGETYPE}-${KERNEL_VERSION}-${PV}"
+   if [ -f /boot/grub/grub.cfg ]; then
+   rootfs=`grep " *linux [^ ].* root=" /boot/grub/grub.cfg 
-m 1 | \
+sed "s# *linux [^ ].* root=#linux 
/${KERNEL_IMAGETYPE}-${KERNEL_VERSION} root=#"`
+
+   echo "menuentry \"$title\" {"
+   echo "set root=(hd0,1)"
+   echo "$rootfs"
+   echo "}"
+   elif [ -f /boot/grub/menu.list ] ; then
+   rootfs=`grep "kernel [^ ].* root=" /boot/grub/menu.list 
-m 1 | \
+sed "s#kernel [^ ].* root=#kernel 
/${KERNEL_IMAGETYPE}-${KERNEL_VERSION} root=#"`
+
+   echo "default 0"
+   echo "timeout 30"
+   echo "title $title"
+   echo "root  (hd0,0)"
+   echo "$rootfs"
+   fi
+   }
+
+   get_old_grub_cfg() {
+   if [ -f /boot/grub/grub.cfg ]; then
+   cat /boot/grub/grub.cfg
+   elif [ -f /boot/grub/menu.list ] ; then
+   cat /boot/grub/menu.list | sed -e '/^default/d' -e 
'/^timeout/d'
+   fi
+   }
+
+   if [ -z "$D" ]; then
+   [ -f /boot/grub/menu.list ] && grubcfg="/boot/grub/menu.list"
+   [ -f /boot/grub/grub.cfg ] && grubcfg="/boot/grub/grub.cfg"
+   if [ -n "$grubcfg" ]; then
+   grubcfgtmp="$grubcfg.tmp"
+   get_new_grub_cfg  > $grubcfgtmp
+   get_old_grub_cfg >> $grubcfgtmp
+   mv $grubcfgtmp $grubcfg
+   echo "Caution! Update kernel may affect kernel-module!"
+   fi
+   fi
+
update-alternatives --install /${KERNEL_IMAGEDEST}/${KERNEL_IMAGETYPE} 
${KERNEL_IMAGETYPE} ${KERNEL_IMAGETYPE}-${KERNEL_VERSION} ${KERNEL_PRIORITY} || 
true
if [ ! -e "$D/lib/modules/${KERNEL_VERSION}" ]; then
 

[OE-core] [PATCH 1/1] update-rc.d.bbclass: change RRECOMMENDS to RDEPENDS

[Qi.Chen]

From: Chen Qi 

If a package inherits update-rc.d.bbclass, it actually needs it to
update the symlinks under /etc/rc?.d/ directories. This is a runtime
dependency. For example, if we try to upgrade the dropbear on target,
its postinst process will need the update-rc.d utility available,
otherwise, the upgrade process will fail.

Besides, if we only recommend update-rc.d, the do_rootfs process will
fail once NO_RRECOMMENDATIONS is enabled. Because in OE, we try to do
the postinsts at rootfs time.

This patch fixes this problem by changing the RRECOMMENDS to RDEPENDS
to let the packages actually rdepend on update-rc.d.

[YOCTO #5169]

Signed-off-by: Chen Qi 
---
 meta/classes/update-rc.d.bbclass |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/update-rc.d.bbclass b/meta/classes/update-rc.d.bbclass
index 5588569..3dee13a 100644
--- a/meta/classes/update-rc.d.bbclass
+++ b/meta/classes/update-rc.d.bbclass
@@ -6,7 +6,7 @@ UPDATERCD_virtclass-cross = ""
 UPDATERCD_class-native = ""
 UPDATERCD_class-nativesdk = ""
 
-RRECOMMENDS_${UPDATERCPN}_append = " ${UPDATERCD}"
+RDEPENDS_${UPDATERCPN}_append = " ${UPDATERCD}"
 
 INITSCRIPT_PARAMS ?= "defaults"
 
-- 
1.7.9.5

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 0/1] update-rc.d.bbclass: change RRECOMMENDS to RDEPENDS

[Qi.Chen]

From: Chen Qi 

The following changes since commit bd76847d867f9f76f76f033439cfb834cf59380f:

  libnewt-python: Don't write a whiptail package (2013-09-12 08:23:42 +0100)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib ChenQi/updatercd-rdepends
  
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/updatercd-rdepends

Chen Qi (1):
  update-rc.d.bbclass: change RRECOMMENDS to RDEPENDS

 meta/classes/update-rc.d.bbclass |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
1.7.9.5

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 0/1] icu-native: do_install: Segmentation fault

[Robert Yang]

The following changes since commit bd76847d867f9f76f76f033439cfb834cf59380f:

  libnewt-python: Don't write a whiptail package (2013-09-12 08:23:42 +0100)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib robert/icu
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=robert/icu

Robert Yang (1):
  icu-native: do_install: Segmentation fault

 .../icu/icu-51.2/icu-pkgdata-large-cmd.patch   |   29 
 meta/recipes-support/icu/icu_51.2.bb   |4 ++-
 2 files changed, 32 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-support/icu/icu-51.2/icu-pkgdata-large-cmd.patch

-- 
1.7.10.4

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/1] icu-native: do_install: Segmentation fault

[Robert Yang]

There was a "Segmentation fault" error when build icu-native when the
TMPDIR is in a deep directory (for example, when len(readlink -f $TMPDIR
== 410)), use LARGE_BUFFER_MAX_SIZE for cmd rather than
SMALL_BUFFER_MAX_SIZE would fix the problem, this should be a misplay
because other cmd uses LARGE_BUFFER_MAX_SIZE.

[YOCTO #5171]

Signed-off-by: Robert Yang 
---
 .../icu/icu-51.2/icu-pkgdata-large-cmd.patch   |   29 
 meta/recipes-support/icu/icu_51.2.bb   |4 ++-
 2 files changed, 32 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-support/icu/icu-51.2/icu-pkgdata-large-cmd.patch

diff --git a/meta/recipes-support/icu/icu-51.2/icu-pkgdata-large-cmd.patch 
b/meta/recipes-support/icu/icu-51.2/icu-pkgdata-large-cmd.patch
new file mode 100644
index 000..6e40659
--- /dev/null
+++ b/meta/recipes-support/icu/icu-51.2/icu-pkgdata-large-cmd.patch
@@ -0,0 +1,29 @@
+pkgdata.cpp: use LARGE_BUFFER_MAX_SIZE for cmd
+
+Use LARGE_BUFFER_MAX_SIZE for cmd rather than SMALL_BUFFER_MAX_SIZE,
+otherwise there was a Segmentation fault error when the command line is
+long, this should be a misplay since other cmd uses
+LARGE_BUFFER_MAX_SIZE.
+
+Upstream-Status: Pending
+
+Signed-off-by: Robert Yang 
+---
+ tools/pkgdata/pkgdata.cpp |2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/tools/pkgdata/pkgdata.cpp b/tools/pkgdata/pkgdata.cpp
+--- a/tools/pkgdata/pkgdata.cpp
 b/tools/pkgdata/pkgdata.cpp
+@@ -1019,7 +1019,7 @@ normal_symlink_mode:
+ 
+ static int32_t pkg_installLibrary(const char *installDir, const char 
*targetDir, UBool noVersion) {
+ int32_t result = 0;
+-char cmd[SMALL_BUFFER_MAX_SIZE];
++char cmd[LARGE_BUFFER_MAX_SIZE];
+ 
+ sprintf(cmd, "cd %s && %s %s %s%s%s",
+ targetDir,
+-- 
+1.7.10.4
+
diff --git a/meta/recipes-support/icu/icu_51.2.bb 
b/meta/recipes-support/icu/icu_51.2.bb
index e865ba6..1278d22 100644
--- a/meta/recipes-support/icu/icu_51.2.bb
+++ b/meta/recipes-support/icu/icu_51.2.bb
@@ -5,7 +5,9 @@ LIC_FILES_CHKSUM = 
"file://../license.html;md5=443a74288a72fad9069a74e7637192c1"
 PR = "r0"
 
 BASE_SRC_URI = 
"http://download.icu-project.org/files/icu4c/${PV}/icu4c-51_2-src.tgz";
-SRC_URI = "${BASE_SRC_URI}"
+SRC_URI = "${BASE_SRC_URI} \
+   file://icu-pkgdata-large-cmd.patch \
+  "
 
 SRC_URI[md5sum] = "072e501b87065f3a0ca888f1b5165709"
 SRC_URI[sha256sum] = 
"deb027a05f1b3bec03298b96fb93b28c84e9683c22e6f94effa67fdc7bd704cc"
-- 
1.7.10.4

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] bluez4/5: Add EXCLUDE_FROM_WORLD = 1

[Paul Eggleton]

On Wednesday 11 September 2013 14:38:01 Saul Wold wrote:
> We can't build both recipes in the world build as there is a collision of
> package name and PR values. Specificly the libasound-module-bluez which is
> the same in both goes backwards from r5 (bluez4) -> r0 (bluez5) and the
> subpackage_metadata check fails:
> 
> ERROR: Recipe lib32-bluez5 is trying to change PR from 'r0' to 'r5'. This
> will cause do_package_write_* failures since the incorrect data will be
> used and they will be unable to find the right workdir.
> 
> [YOCTO #5165]
> 
> Signed-off-by: Saul Wold 
> ---
>  meta/recipes-connectivity/bluez/bluez4.inc  | 1 +
>  meta/recipes-connectivity/bluez5/bluez5.inc | 2 ++
>  2 files changed, 3 insertions(+)
> 
> diff --git a/meta/recipes-connectivity/bluez/bluez4.inc
> b/meta/recipes-connectivity/bluez/bluez4.inc index b540622..e4f6834 100644
> --- a/meta/recipes-connectivity/bluez/bluez4.inc
> +++ b/meta/recipes-connectivity/bluez/bluez4.inc
> @@ -43,3 +43,4 @@ EXTRA_OECONF = "\
>--with-udevrulesdir=`pkg-config --variable=udevdir udev`/rules.d \
>  "
> 
> +EXCLUDE_FROM_WORLD = "1"
> diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc
> b/meta/recipes-connectivity/bluez5/bluez5.inc index e5cb9e8..2e25d86 100644
> --- a/meta/recipes-connectivity/bluez5/bluez5.inc
> +++ b/meta/recipes-connectivity/bluez5/bluez5.inc
> @@ -82,3 +82,5 @@ FILES_${PN}-dbg += "\
>  RDEPENDS_${PN}-testtools += "python python-dbus python-pygobject"
> 
>  SYSTEMD_SERVICE_${PN} = "bluetooth.service"
> +
> +EXCLUDE_FROM_WORLD = "1"

Surely we don't need to exclude both from world, just one of them?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 0/1] perf: source should be ready after do_unpack

[Robert Yang]

The following changes since commit bd76847d867f9f76f76f033439cfb834cf59380f:

  libnewt-python: Don't write a whiptail package (2013-09-12 08:23:42 +0100)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib robert/perf
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=robert/perf

Robert Yang (1):
  perf: source should be ready after do_unpack

 meta/recipes-kernel/perf/perf.bb |3 +++
 1 file changed, 3 insertions(+)

-- 
1.7.10.4

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/1] perf: source should be ready after do_unpack

[Robert Yang]

In perf.bb:

S = "${STAGING_KERNEL_DIR}"

So the source should be ready after the do_unpack, and we need this:

do_unpack[depends] += "virtual/kernel:do_populate_sysroot"

Otherwise, maybe no source after do_unpack.

[YOCTO #5168]

Signed-off-by: Robert Yang 
---
 meta/recipes-kernel/perf/perf.bb |3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/perf.bb
index a78fc05..d2c1048 100644
--- a/meta/recipes-kernel/perf/perf.bb
+++ b/meta/recipes-kernel/perf/perf.bb
@@ -52,6 +52,9 @@ export PERL_LIB = 
"${STAGING_LIBDIR}${PERL_OWN_DIR}/perl/${@get_perl_version(d)}
 export PERL_ARCHLIB = 
"${STAGING_LIBDIR}${PERL_OWN_DIR}/perl/${@get_perl_version(d)}"
 
 S = "${STAGING_KERNEL_DIR}"
+# The source should be ready after the do_unpack
+do_unpack[depends] += "virtual/kernel:do_populate_sysroot"
+
 B = "${WORKDIR}/${BPN}-${PV}"
 
 SCRIPTING_DEFINES = "${@perf_feature_enabled('perf-scripting', '', 
'NO_LIBPERL=1 NO_LIBPYTHON=1',d)}"
-- 
1.7.10.4

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/1] kernel.bbclass: Need a method to install/update for bzImage

[Hongxu Jia]

While installing a rpm to update kernel on a deployed target, it will update
the boot area and the boot menu with the kernel as the priority but allow
you to fall back to the original kernel as well.

- In pre-install script, it backs up original kernel to avoid confliction with
  new one.
- In post-install script, it updates the new kernel as the boot priority.

[YOCTO #4104]

Signed-off-by: Hongxu Jia 
---
 meta/classes/kernel.bbclass | 65 +
 1 file changed, 65 insertions(+)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index e039dfc..f0dd679 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -263,7 +263,72 @@ ALLOW_EMPTY_kernel-image = "1"
 ALLOW_EMPTY_kernel-modules = "1"
 DESCRIPTION_kernel-modules = "Kernel modules meta package"
 
+pkg_preinst_kernel-image () {
+   if [ -z "$D" ]; then
+   # Parsing confliction
+   [ -f /boot/grub/menu.list ] && grubcfg="/boot/grub/menu.list"
+   [ -f /boot/grub/grub.cfg ] && grubcfg="/boot/grub/grub.cfg"
+   if [ -n "$grubcfg" ]; then
+   # Dereference symlink to avoid confliction with new 
kernel name.
+   if grep -q "/${KERNEL_IMAGETYPE} root=" $grubcfg; then
+   kimage=`realpath /boot/${KERNEL_IMAGETYPE}`;
+   sed -i "s#${KERNEL_IMAGETYPE} 
root=#${kimage##*/} root=#" $grubcfg
+   fi
+
+   # Rename old kernel if it conflicts with new kernel 
name.
+   if grep -q "/${KERNEL_IMAGETYPE}-${KERNEL_VERSION} 
root=" $grubcfg; then
+   timestamp=`date +%s`
+   
kimage="/boot/${KERNEL_IMAGETYPE}-${KERNEL_VERSION}-$timestamp-back"
+   sed -i "s#${KERNEL_IMAGETYPE}-${KERNEL_VERSION} 
root=#${kimage##*/} root=#" $grubcfg
+   mv /boot/${KERNEL_IMAGETYPE}-${KERNEL_VERSION} 
$kimage
+   fi
+   fi
+   fi
+}
+
 pkg_postinst_kernel-image () {
+   get_new_grub_cfg() {
+   title="Update ${KERNEL_IMAGETYPE}-${KERNEL_VERSION}-${PV}"
+   if [ -f /boot/grub/grub.cfg ]; then
+   rootfs=`grep " *linux [^ ].* root=" /boot/grub/grub.cfg 
-m 1 | \
+sed "s# *linux [^ ].* root=#linux 
/${KERNEL_IMAGETYPE}-${KERNEL_VERSION} root=#"`
+
+   echo "menuentry \"$title\" {"
+   echo "set root=(hd0,1)"
+   echo "$rootfs"
+   echo "}"
+   elif [ -f /boot/grub/menu.list ] ; then
+   rootfs=`grep "kernel [^ ].* root=" /boot/grub/menu.list 
-m 1 | \
+sed "s#kernel [^ ].* root=#kernel 
/${KERNEL_IMAGETYPE}-${KERNEL_VERSION} root=#"`
+
+   echo "default 0"
+   echo "timeout 30"
+   echo "title $title"
+   echo "root  (hd0,0)"
+   echo "$rootfs"
+   fi
+   }
+
+   get_old_grub_cfg() {
+   if [ -f /boot/grub/grub.cfg ]; then
+   cat /boot/grub/grub.cfg
+   elif [ -f /boot/grub/menu.list ] ; then
+   cat /boot/grub/menu.list | sed -e '/^default/d' -e 
'/^timeout/d'
+   fi
+   }
+
+   if [ -z "$D" ]; then
+   [ -f /boot/grub/menu.list ] && grubcfg="/boot/grub/menu.list"
+   [ -f /boot/grub/grub.cfg ] && grubcfg="/boot/grub/grub.cfg"
+   if [ -n "$grubcfg" ]; then
+   grubcfgtmp="$grubcfg.tmp"
+   get_new_grub_cfg  > $grubcfgtmp
+   get_old_grub_cfg >> $grubcfgtmp
+   mv $grubcfgtmp $grubcfg
+   echo "Caution! Update kernel may affect kernel-module!"
+   fi
+   fi
+
update-alternatives --install /${KERNEL_IMAGEDEST}/${KERNEL_IMAGETYPE} 
${KERNEL_IMAGETYPE} ${KERNEL_IMAGETYPE}-${KERNEL_VERSION} ${KERNEL_PRIORITY} || 
true
if [ ! -e "$D/lib/modules/${KERNEL_VERSION}" ]; then
mkdir -p $D/lib/modules/${KERNEL_VERSION}
-- 
1.8.1.2

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 0/1] kernel.bbclass: Need a method to install/update for bzImage

[Hongxu Jia]

Test Case:
1. Prepare a deployed target, and make sure your boot area has enough disk
   space.

2. Download the new kernel image rpm to the target

3. Before install/update, check boot area and menu
root@qemux86:~# ls /boot/
grubvmlinuz

root@qemux86:~# cat /boot/grub/grub.cfg
menuentry "Linux" {
set root=(hd0,1)
linux /vmlinuz root=/dev/hdb2  rw  console=tty0  quiet
}

4. Install/update bzImage
root@qemux86:~# rpm -i 
kernel-image-3.10.9-yocto-standard-3.10.9+git0+cd502a8814_7144bcc4b8-r0.qemux86.rpm
 
Caution! Update kernel may affect kernel-module!
update-alternatives: Linking //boot/bzImage to bzImage-3.10.9-yocto-standard

5. After install/update, check boot area and menu
root@qemux86:~# ls /boot/ -al
drwxr-xr-x4 root root  1024 Sep 12 08:48 .
drwxr-xr-x   17 root root  4096 Sep 12 07:08 ..
lrwxrwxrwx1 root root29 Sep 12 08:48 bzImage -> 
bzImage-3.10.9-yocto-standard
-rw-r--r--1 root root   6172096 Sep 12 07:39 
bzImage-3.10.9-yocto-standard
drwxr-xr-x4 root root  1024 Sep 12 08:48 grub
-rwxr-x---1 root root   6172096 Sep 12 08:45 vmlinuz

root@qemux86:~# cat /boot/grub/grub.cfg 
menuentry "Update 
bzImage-3.10.9-yocto-standard-3.10.9+gitAUTOINC+cd502a8814_7144bcc4b8" {
set root=(hd0,1)
linux /bzImage-3.10.9-yocto-standard root=/dev/hdb2  rw  console=tty0  quiet
}
menuentry "Linux" {
set root=(hd0,1)
linux /vmlinuz root=/dev/hdb2  rw  console=tty0  quiet
}

6. Reboot target, 'Update 
bzImage-3.10.9-yocto-standard-3.10.9+gitAUTOINC+cd502a8814_7144bcc4b8'
   will be in the boot menu.

7. It supports GRUB 0.97 in which the grub.cfg doesn't exist and menu.lst
   is used.

8. If you install the same rpm more than one time with '--force', there will
   be multiple kernel images in boot area and menu.

//Hongxu


The following changes since commit 1b814498b60d5f354d8cc5bdf568b91baf0745dc:

  bitbake: bitbake/cooker: fix some calls of cookerdata.findConfigFile method 
(2013-09-02 12:26:20 +0100)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib hongxu/update-bzimage
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=hongxu/update-bzimage

Hongxu Jia (1):
  kernel.bbclass: Need a method to install/update for bzImage

 meta/classes/kernel.bbclass | 65 +
 1 file changed, 65 insertions(+)

-- 
1.8.1.2

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] image/populate_sdk: Ensure symlinks in target sysroot are relative

[Hans Beckérus]

On Thu, Sep 12, 2013 at 10:02 AM, Richard Purdie
 wrote:
> On Thu, 2013-09-12 at 09:48 +0200, Hans Beckérus wrote:
>> I have a slight problem with this patch. The new
>> sysroot-relativelinks.py does not obtain the proper access protection
>> bits!?
>> Which results in the following error when packaging the SDK
>>
>> /home/poky/build/tmp/work/zynq_zc706-poky-linux-gnueabi/rootfs-default/1.0-r0/temp/run.populate_sdk_image.20803:
>> line 496: /home/poky/scripts/sysroot-relativelinks.py: Permission
>> denied
>>
>> [home/poky]: ls -l scripts/sysroot-relativelinks.py
>> -rw-rw-r-- 1  poky poky 959 Sep 12 09:38 scripts/sysroot-relativelinks.py
>>
>> The execution bit is missing!?
>>
>> I can of course apply the execution bit manually, but what may cause
>> the patch to not set the bits properly in my scripts folder for new
>> files? Please advise.
>
> I checked the poky and oe-core trees and they have a+x:
>
> http://git.yoctoproject.org/cgit.cgi/poky/tree/scripts
> http://git.openembedded.org/openembedded-core/tree/scripts
>
> so I'm a bit puzzled. How did you update your tree?
>
All the other scripts in the scripts folder has a+x, it is only the
new .py file added by your patch that does not obtain it in my local
tree.

> Cheers,
>
> Richard
>
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] image/populate_sdk: Ensure symlinks in target sysroot are relative

[Richard Purdie]

On Thu, 2013-09-12 at 09:48 +0200, Hans Beckérus wrote:
> I have a slight problem with this patch. The new
> sysroot-relativelinks.py does not obtain the proper access protection
> bits!?
> Which results in the following error when packaging the SDK
> 
> /home/poky/build/tmp/work/zynq_zc706-poky-linux-gnueabi/rootfs-default/1.0-r0/temp/run.populate_sdk_image.20803:
> line 496: /home/poky/scripts/sysroot-relativelinks.py: Permission
> denied
> 
> [home/poky]: ls -l scripts/sysroot-relativelinks.py
> -rw-rw-r-- 1  poky poky 959 Sep 12 09:38 scripts/sysroot-relativelinks.py
> 
> The execution bit is missing!?
> 
> I can of course apply the execution bit manually, but what may cause
> the patch to not set the bits properly in my scripts folder for new
> files? Please advise.

I checked the poky and oe-core trees and they have a+x:

http://git.yoctoproject.org/cgit.cgi/poky/tree/scripts
http://git.openembedded.org/openembedded-core/tree/scripts

so I'm a bit puzzled. How did you update your tree?

Cheers,

Richard

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] image/populate_sdk: Ensure symlinks in target sysroot are relative

[Hans Beckérus]

I have a slight problem with this patch. The new
sysroot-relativelinks.py does not obtain the proper access protection
bits!?
Which results in the following error when packaging the SDK

/home/poky/build/tmp/work/zynq_zc706-poky-linux-gnueabi/rootfs-default/1.0-r0/temp/run.populate_sdk_image.20803:
line 496: /home/poky/scripts/sysroot-relativelinks.py: Permission
denied

[home/poky]: ls -l scripts/sysroot-relativelinks.py
-rw-rw-r-- 1  poky poky 959 Sep 12 09:38 scripts/sysroot-relativelinks.py

The execution bit is missing!?

I can of course apply the execution bit manually, but what may cause
the patch to not set the bits properly in my scripts folder for new
files? Please advise.

Thanks.
Hans


On Wed, Sep 11, 2013 at 11:42 AM, Richard Purdie
 wrote:
> In the target sysroot of an SDK we can have target system absolute links
> which don't make sense. This adds a script which fixes them up to become 
> relative
> paths instead.
>
> [YOCTO #5020]
>
> Signed-off-by: Richard Purdie 
> ---
> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
> index 4a0946c..f1e62f14 100644
> --- a/meta/classes/image.bbclass
> +++ b/meta/classes/image.bbclass
> @@ -4,7 +4,7 @@ inherit populate_sdk_base
>
>  TOOLCHAIN_TARGET_TASK += "${PACKAGE_INSTALL}"
>  TOOLCHAIN_TARGET_TASK_ATTEMPTONLY += "${PACKAGE_INSTALL_ATTEMPTONLY}"
> -POPULATE_SDK_POST_TARGET_COMMAND += "rootfs_install_complementary 
> populate_sdk; "
> +POPULATE_SDK_POST_TARGET_COMMAND += "rootfs_install_complementary 
> populate_sdk; rootfs_sysroot_relativelinks; "
>
>  inherit gzipnative
>
> @@ -617,6 +617,11 @@ rootfs_trim_schemas () {
> done
>  }
>
> +# Make any absolute links in a sysroot relative
> +rootfs_sysroot_relativelinks () {
> +   sysroot-relativelinks.py ${SDK_OUTPUT}/${SDKTARGETSYSROOT}
> +}
> +
>  EXPORT_FUNCTIONS zap_root_password remove_init_link do_rootfs 
> make_zimage_symlink_relative set_image_autologin rootfs_update_timestamp 
> rootfs_no_x_startup
>
>  do_fetch[noexec] = "1"
> diff --git a/scripts/sysroot-relativelinks.py 
> b/scripts/sysroot-relativelinks.py
> new file mode 100755
> index 000..2e13744
> --- /dev/null
> +++ b/scripts/sysroot-relativelinks.py
> @@ -0,0 +1,31 @@
> +#!/usr/bin/env python
> +import sys
> +import os
> +
> +# Take a sysroot directory and turn all the abolute symlinks and turn them 
> into
> +# relative ones such that the sysroot is usable within another system.
> +
> +if len(sys.argv) != 2:
> +print("Usage is " + sys.argv[0] + "")
> +sys.exit(1)
> +
> +topdir = sys.argv[1]
> +topdir = os.path.abspath(topdir)
> +
> +def handlelink(filep, subdir):
> +link = os.readlink(filep)
> +if link[0] != "/":
> +return
> +if link.startswith(topdir):
> +return
> +#print("Replacing %s with %s for %s" % (link, topdir+link, filep))
> +print("Replacing %s with %s for %s" % (link, 
> os.path.relpath(topdir+link, subdir), filep))
> +os.unlink(filep)
> +os.symlink(os.path.relpath(topdir+link, subdir), filep)
> +
> +for subdir, dirs, files in os.walk(topdir):
> +for f in files:
> +filep = os.path.join(subdir, f)
> +if os.path.islink(filep):
> +#print("Considering %s" % filep)
> +handlelink(filep, subdir)
>
>
>
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/3] ia32-base: only depend on GL if opengl DISTRO_FEATURE enabled

[Burton, Ross]

On 12 September 2013 02:17, Darren Hart  wrote:
> I thought the idea was to try to build with --disable-gl or similar if
> the DISTRO_FEATURES didn't include opengl, rather than disable the
> driver entirely.
>
> Am I remembering incorrectly, or was there more discussion on that which
> showed that couldn't be made to work?

Orthogonal issues.  We're building the xf86-video-intel without DRI/GL
support in that case, but the machine recommends in ia32-base are
currently always pulling in the Mesa drivers (which we're not
building) and the server-side GLX support (which we're not building).

Ross
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFC PATCH] bitbake.conf: Stop providing ${P} and ${PF} by default

[Robert Yang]

I've done a world build on qemux86 with:

PROVIDES_prepend = "${PN} "

it worked well.

// Robert

On 09/09/2013 10:14 PM, Richard Purdie wrote:

For a long time we've provided PN-PV and PN-PV-PR by tweaking PROVIDES. This 
looks
nice at first glance however it turns out to be a bit problematic. Taking make 
as an
example where there are two versions, 3.81 and 3.82, what should "bitbake 
make-3.81" do?

Currently it builds make-3.81 and make-3.82 and breaks in interesting ways. Is 
that
a bitbake bug? Well, it certainly shouldn't try and run the build. Why is it 
building
3.82 though? Its due to finding a dependency on "make-dev" and then trying to 
figure
out what provides it? The answer is "make" and the default version of "make" is 
3.82.

So arguably, finding "make-3.81" should infer PREFERRED_VERSION_make = "3.81". 
Doing
so resolved the above problem since now "make" resolves to "make-3.81".

So what about if we have Recipe A:
DEPENDS = "make-3.81"
and Recipe B:
DEPENDS = "make-3.82"

That is clearly an error, easy. So finally what about if we have Recipe A:
DEPENDS = "make-3.81"
and Recipe B:
DEPENDS = "make"

The first recipe infers the PREFERRED_VERSION_make = "3.81" and then forces that
version on everything else. Is that desired? Probably not in most cases, at 
least not
silently.

As mitigation, we could print a WARNING about this happening. The final part of 
the problem
is that we can ony figure this out within bitbake itself. That means we'd have 
to teach bitbake
about the PN-PV format of PROVIDES which is breaking the separation between 
bitbake and the
metadata. We can't win :(.

Nobody that I know of is using or relying on this functionality so perhaps we 
should
just remove it instead which is what this patch does. Opinions?

Signed-off-by: Richard Purdie 
---
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 2d19d86..578c7d0 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -253,7 +253,7 @@ DEPCHAIN_POST = "-dev -dbg"
  DEPENDS = ""
  RDEPENDS = ""
  PROVIDES = ""
-PROVIDES_prepend = "${P} ${PF} ${PN} "
+PROVIDES_prepend = "${PN} "
  RPROVIDES = ""

  MULTI_PROVIDER_WHITELIST = "virtual/libintl virtual/libintl-native 
virtual/nativesdk-libintl virtual/xserver virtual/update-alternatives-native 
virtual/update-alternatives"


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core



___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core