Re: [OE-core] Deployment for machine X will remove its results from machine Y's deploy dir

[Mike Looijmans]

On 11/27/2014 05:21 PM, Richard Purdie wrote:

On Thu, 2014-11-27 at 16:17 +0100, Mike Looijmans wrote:

If I understand correctly, having two "MACHINE" share the same
MACHINE_ARCH (which is the case for several intel boards too), is not
actually allowed?

Because you get the same kernel/bootloader for different machines then.
That's what I wanted, and that triggered me finding this issue.


Its a very good question. As things stand today, there is a one to one
mapping between MACHINE_ARCH and MACHINE, the difference being the
removal of invalid characters for the package namespace. That implies
that no, its not allowed.


Okay... So I have to revert that, even through it worked remarkably well so 
far (until I found this issue - compared to the situation before that, this is 
still a vast improvement).



The intel boards you mention do something a little different, they
inject a new "arch" into the hierarchy and then several machines share
that common "arch".


Yeah. I did basically the opposite, I expanded the MACHINE with an extra 
suffix and then stripped the suffix away when composing the MACHINE_ARCH.



I suspect the intel boards you mention do suffer from the issue you
mention in a related way and the fix may be to s/MACHINE/PACKAGE_ARCH/
in DEPLOY_DIR_IMAGE as previously mentioned. The difference is I suspect
they deploy for the first machine built and then not for any other.
Nitin/Darren may be interested in checking into that.


Yes.

But if I set DEPOY_DIR_IMAGE to use MACHINE_ARCH, I get the opposite problem 
of two MACHINEs overwriting eachothers root filesystem. Though the $MACHINE in 
most of the filenames (which is typically removed for the links) might help 
separate those.



Please realize that the example is just an example. The actual problem
I'm experiencing is with the kernel and bootloader!


Right, the allarch behaviour is an illustration but not the underlying
problem you need to resolve (although its related).


Well, I thought I had it all sorted out, but I'm back to square one now.

What I'm really trying to do here is to create another "dimension".

The board contains a combined ARM + FPGA. The ARM part is just like any other 
machine, and it's the same on all boards.


The FPGA part also needs things built in the OE environment, and it has its 
own OS and "applications" in the form of a static bitstream to configure the 
whole device, and partial bitstreams that are swapped in and out at runtime to 
use it for various different functions. The build structure works much like a 
normal CPU toolchain, in that it creates the full bitstream which provides the 
"library" (Xilinx calls this a checkpoint) for the partials.
The FPGA can be of different types (currently we have xc7z015 and xc7z030 
boards, but there are plans to create SOMs for various other types too), and 
the bistreams are unique for each type, unlike CPU code, you cannot exchange 
them. The FPGA recipes leave these checkpoints into the sysroot where other 
FPGA recipes can pick them up and expand on them. Hence, I can't just make 
separate recipes for different FPGA types, because they need the sysroot to be 
specific to them.


So what I did was define the MACHINE as a combination of SOM+carrier+FPGA. The 
SOM+carrier part went into SOM_FAMILY and MACHINE_ARCH, and the FPGA part into 
the "FPGA_FAMILY" (and an FPGA_FAMILY_ARCH). The FPGA recipes use PACKAGE_ARCH 
= "${FPGA_FAMILY_ARCH}".


This config file sets that up:
https://github.com/topic-embedded-products/meta-topic/blob/master/conf/machine/include/topic-miami.inc

This has so far accomplished what I wanted to do, It makes all the ARM part 
things (like kernel and bootloader) generic, because they don't depend on the 
type of FPGA at all. And it makes the FPGA parts independent of the ARM side 
too, drastically reducing build times (FPGA bitstreams typically take 1 to 4 
hours to build, and that's for the smaller devices..) and heavily leaning on 
shares sstate-cache so we can re-use a buildserver's nightly output all over 
the place.


Another approach would be to introduce a global variable (FPGA_FAMILY?) that 
has the same level as MACHINE does, and require it to be set in local.conf or 
environment.
By explicitly using FPGA_FAMILY in intermediate and output paths, I think I 
can make it so that the sysroot can still hold the intermediate files for 
various targets. And simply including FPGA_FAMILY in the rootfs image name 
should solve the deployment issue.


I think more machines will emerge that need this kind of setup. The kernel has 
already gotten quite good at supporting hardware that can just grow itself a 
network card or i2c controller when it needs one...



Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
Telefax:  (+31) (0) 499 33 69 70
E-mail: mike.looijm...@topic.nl
Website: www.topic.nl

Pleas

[OE-core] [PATCH 0/2] qt4: allow builds for mips64 but disable webkit for n32

[jackie.huang]

From: Jackie Huang 

The following changes since commit ff2ff155ea5273b2023a1c9834b13f10249d343f:

  gdk-pixbuf: use ptest-gnome (2014-11-25 12:58:21 +)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib jhuang0/d_qt4-webkit_0
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=jhuang0/d_qt4-webkit_0

Jackie Huang (2):
  Revert "qt4*.bbclass: disable build qt on mips64 with 64 bits
userspace"
  qt4: disable webkit for mips64 n32 temporarily

 meta/classes/qt4e.bbclass |3 ---
 meta/classes/qt4x11.bbclass   |3 ---
 meta/recipes-qt/qt4/qt4-4.8.6.inc |5 +
 3 files changed, 5 insertions(+), 6 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 2/2] qt4: disable webkit for mips64 n32 temporarily

[jackie.huang]

From: Jackie Huang 

Disable webkit for mips64 n32 temporarily that fails to compile.

The webkit package also disable the build for n32:
f5c4d18 webkit/midori: block to build webkit on mips64 with libn32 ABI

The opened defect in qt upstream is:
https://bugreports.qt-project.org/browse/QTBUG-39224

Signed-off-by: Jackie Huang 
---
 meta/recipes-qt/qt4/qt4-4.8.6.inc |5 +
 1 file changed, 5 insertions(+)

diff --git a/meta/recipes-qt/qt4/qt4-4.8.6.inc 
b/meta/recipes-qt/qt4/qt4-4.8.6.inc
index ae6692b..924a6ad 100644
--- a/meta/recipes-qt/qt4/qt4-4.8.6.inc
+++ b/meta/recipes-qt/qt4/qt4-4.8.6.inc
@@ -31,6 +31,11 @@ SRC_URI[sha256sum] = 
"8b14dd91b52862e09b8e6a963507b74bc2580787d171feda197badfa70
 
 S = "${WORKDIR}/qt-everywhere-opensource-src-${PV}"
 
+# disable webkit for mips64 n32 temporarily that fails to compile,
+# qt upstream defect:
+# https://bugreports.qt-project.org/browse/QTBUG-39224
+QT_CONFIG_FLAGS_append_mips64 = "${@bb.utils.contains("TUNE_FEATURES", "n32", 
" -no-webkit", "" ,d)}"
+
 FILES_${QT_BASE_NAME}-tools_append = " ${bindir}/qml 
${bindir}/qmlplugindump"
 FILES_${QT_BASE_NAME}-tools-dbg_append = " ${bindir}/.debug/qml 
${bindir}/.debug/qmlplugindump"
 
-- 
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/2] Revert "qt4*.bbclass: disable build qt on mips64 with 64 bits userspace"

[jackie.huang]

From: Jackie Huang 

This reverts commit 17890ebd637da0b3bf78804002d8b4f0ace078d2.

qt4 is upgraded to 4.8.6 and this is fixed by:
c889b40 qt webkit: add support for MIPS64 platforms

so revert the commit.

Signed-off-by: Jackie Huang 
---
 meta/classes/qt4e.bbclass   |3 ---
 meta/classes/qt4x11.bbclass |3 ---
 2 files changed, 6 deletions(-)

diff --git a/meta/classes/qt4e.bbclass b/meta/classes/qt4e.bbclass
index 850bb6a..13b1050 100644
--- a/meta/classes/qt4e.bbclass
+++ b/meta/classes/qt4e.bbclass
@@ -19,6 +19,3 @@ EXTRA_QMAKEVARS_PRE += " QT_LIBINFIX=${QT_LIBINFIX} "
 
 # Qt4 uses atomic instructions not supported in thumb mode
 ARM_INSTRUCTION_SET = "arm"
-
-# Qt4 could NOT be built on MIPS64 with 64 bits userspace
-COMPATIBLE_HOST_mips64 = "mips64.*-linux-gnun32"
diff --git a/meta/classes/qt4x11.bbclass b/meta/classes/qt4x11.bbclass
index 65d196a..b06e15d 100644
--- a/meta/classes/qt4x11.bbclass
+++ b/meta/classes/qt4x11.bbclass
@@ -9,6 +9,3 @@ QT_LIBINFIX = ""
 
 # Qt4 uses atomic instructions not supported in thumb mode
 ARM_INSTRUCTION_SET = "arm"
-
-# Qt4 could NOT be built on MIPS64 with 64 bits userspace
-COMPATIBLE_HOST_mips64 = "mips64.*-linux-gnun32"
-- 
1.7.9.5

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

[OE-core] [PATCH 01/12] distrodata_class: checkpkg make usage of latest_versionstring methods in bitbake fetcher

[Aníbal Limón]

Because methods for get latest version of upstream package are now available
into bitbake removes duplicated code and make use of it.

Compatibility testing was made running distrodata class and the result files
can be found at:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=1813

[YOCTO #1813]

Signed-off-by: Aníbal Limón 
---
 meta/classes/distrodata.bbclass | 492 
 1 file changed, 43 insertions(+), 449 deletions(-)

diff --git a/meta/classes/distrodata.bbclass b/meta/classes/distrodata.bbclass
index a890de7..83aa381 100644
--- a/meta/classes/distrodata.bbclass
+++ b/meta/classes/distrodata.bbclass
@@ -268,240 +268,6 @@ python do_checkpkg() {
 import tempfile
 import subprocess
 
-"""
-sanity check to ensure same name and type. Match as many patterns as 
possible
-such as:
-gnome-common-2.20.0.tar.gz (most common format)
-gtk+-2.90.1.tar.gz
-xf86-input-synaptics-12.6.9.tar.gz
-dri2proto-2.3.tar.gz
-blktool_4.orig.tar.gz
-libid3tag-0.15.1b.tar.gz
-unzip552.tar.gz
-icu4c-3_6-src.tgz
-genext2fs_1.3.orig.tar.gz
-gst-fluendo-mp3
-"""
-prefix1 = "[a-zA-Z][a-zA-Z0-9]*([\-_][a-zA-Z]\w+)*\+?[\-_]"# 
match most patterns which uses "-" as separator to version digits
-prefix2 = "[a-zA-Z]+"# a loose pattern such as 
for unzip552.tar.gz
-prefix3 = "[0-9]+[\-]?[a-zA-Z]+"# a loose 
pattern such as for 80325-quicky-0.4.tar.gz
-prefix = "(%s|%s|%s)" % (prefix1, prefix2, prefix3)
-ver_regex = "(([A-Z]*\d+[a-zA-Z]*[\.\-_]*)+)"#"((\d+[\.\-_[a-z]])+)"
-# src.rpm extension was added only for rpm package. Can be removed if 
the rpm
-# packaged will always be considered as having to be manually upgraded
-suffix = 
"(tar\.gz|tgz|tar\.bz2|tar\.lz4|zip|xz|rpm|bz2|lz4|orig\.tar\.gz|tar\.xz|src\.tar\.gz|src\.tgz|svnr\d+\.tar\.bz2|stable\.tar\.gz|src\.rpm)"
-
-suffixtuple = ("tar.gz", "tgz", "zip", "tar.bz2", "tar.xz", "tar.lz4", 
"bz2", "lz4", "orig.tar.gz", "src.tar.gz", "src.rpm", "src.tgz", 
"svnr\d+.tar.bz2", "stable.tar.gz", "src.rpm")
-sinterstr = "(?P%s?)v?(?P%s)(\-source)?" % (prefix, 
ver_regex)
-sdirstr = "(?P%s)\.?v?(?P%s)(\-source)?[\.\-](?P%s$)" 
% (prefix, ver_regex, suffix)
-
-def parse_inter(s):
-m = re.search(sinterstr, s)
-if not m:
-return None
-else:
-return (m.group('name'), m.group('ver'), "")
-
-def parse_dir(s):
-m = re.search(sdirstr, s)
-if not m:
-return None
-else:
-return (m.group('name'), m.group('ver'), 
m.group('type'))
-
-def modelate_version(version):
-if version[0] in ['.', '-']:
-if version[1].isdigit():
-version = version[1] + version[0] + 
version[2:len(version)]
-else:
-version = version[1:len(version)]
-
-version = re.sub('\-', '.', version)
-version = re.sub('_', '.', version)
-version = re.sub('(rc)+', '.-1.', version)
-version = re.sub('(alpha)+', '.-3.', version)
-version = re.sub('(beta)+', '.-2.', version)
-if version[0] == 'v':
-version = version[1:len(version)]
-return version
-
-"""
-Check whether 'new' is newer than 'old' version. We use existing 
vercmp() for the
-purpose. PE is cleared in comparison as it's not for build, and PV is 
cleared too
-for simplicity as it's somehow difficult to get from various upstream 
format
-"""
-def __vercmp(old, new):
-(on, ov, ot) = old
-(en, ev, et) = new
-if on != en or (et and et not in suffixtuple):
-return False
-ov = modelate_version(ov)
-ev = modelate_version(ev)
-
-result = bb.utils.vercmp(("0", ov, ""), ("0", ev, ""))
-if result < 0:
-return True
-else:
-return False
-
-"""
-wrapper for fetch upstream directory info
-'url'- upstream link customized by regular expression
-'d'- database
-'tmpf'- tmpfile for fetcher output
-We don't want to exit whole build due to one recipe error. So handle 
all exceptions 
-gracefully w/o leaking to outer. 
-"""
-def internal_fetch_wget(url, ud, d, tmpf):
-status = "ErrFetchUnkno

[OE-core] [PATCH 00/12] Usage bitbake fetcher latest_versionstring in distrodata_class

[Aníbal Limón]

Since Bitbake fetcher has latest_versionstring method that support search last 
version
of package in upstream sites, distrodata class should use it instead of do 
itself,

Summary of changes,

distrodata_class: Re-implement upstream version detection using Bitbake fetcher 
methods.
package_regex.inc: Update regex because Bitbake fetcher already provides 
support for search
in HTML href's tags instead of RAW lines.
bitbake: Improvements in fetcher wget latest_versionstring method based on [1] 
and clean code.

Compatibility testing was made running distrodata class and the result files 
can be found at [1].

The code has DEPENDENCIES the Bitbake changes should be MERGE first then 
package_regex.inc
and finally distrodata_class.

[1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=1813

The following changes since commit 0bc03af7ee6112fa0af0608b02f715ec8495e4ff:

  maintainers.inc: update maintainers (2014-11-26 17:06:10 +)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib alimon/fetcher-distrodata
  
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=alimon/fetcher-distrodata

Aníbal Limón (12):
  distrodata_class: checkpkg make usage of latest_versionstring methods
in bitbake fetcher
  package_regex.inc: Update REGEX'es in order to find upstream versions
correctly
  fetch2/wget.py: latest_versionstring create _init_regex method for
have one place when regex'es are defined
  fetch2/wget.py: _init_regexes rename variables to be more consistent
and move dirver_regex into it
  fetch/wget.php: latest version string only try to find latest
directory when REGEX_URI isn't specified to avoid unnecessary
processing and makes code easier
  fetch2/wget.py: latest_versionstring add package_custom_regex_comp
  fetch2/wget.py: latest_versionstring improvments in searching
  fetch/wget.py: latest_versionstring remove unnecessary usage for name
in version comparision
  fetch2/wget: latest_versionstring add support for search in RAW html
lines
  fetch/wget.py: latest_versionstring remove newuri set because is
previous set
  tests/fetch.py: Update wget latest_versionstring cups case
  fetch2/wget.py: latest_versionstring clean improvments minor

 bitbake/lib/bb/fetch2/wget.py| 146 ---
 bitbake/lib/bb/tests/fetch.py|   2 +-
 meta-yocto/conf/distro/include/package_regex.inc | 400 +-
 meta/classes/distrodata.bbclass  | 492 ++-
 4 files changed, 337 insertions(+), 703 deletions(-)

-- 
1.9.1

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

[OE-core] FW: [PATCH 1/2] spdx: Provide spdx file that meet SPDX 1.2 Version Specification

[Lei, Maohui]

Hi all

  How about this patch? I have submitted for days, but still no responds.



Cheers

Lei Maohui

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Lei,
> Maohui
> Sent: Tuesday, November 25, 2014 9:32 AM
> To: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [oe-core][PATCH 1/2] spdx: Provide spdx file that meet
> SPDX 1.2 Version Specification
> 
> Hi all
> 
> Sorry, commit log is too simple.
> 
> These two patches aim to make the spdx file meet the SPDX 1.2 Version
> Specification. The main changes are:
> 
> 1. use "curl" command instead of "wget" when get spdx file from FOSSologySPDX
> instance server.
> 
>Before apply these patches, the command is :
>wget -qO - --no-check-certificate --timeout=0
> --post-file=xxx/yyy/zzz.tar.gz
> http://localhost//?mod=spdx_license_once&noCopyright=${FOSS_COPYRIGHT}&rec
> ursiveUnpack=${FOSS_RECURSIVE_UNPACK}
> 
>After apply these patches, the command is :
>curl http://127.0.0.1/repo/ --noproxy 127.0.0.1 -k -F
> "mod=spdx_license_once" -F "noCopyright=false" -F "jsonOutput=false" -F
> "fullSPDXFlag=true" -F "file=@ xxx/yyy/zzz.tar.gz" -o xxx/yyy/zzz.spdx
> 
>Because if use "wget" command,the Mandatory fields of the SPDX 
> Specification
> such as the following can't be obtained.
>1) PackageLicenseInfoFromFiles(Package Information)
>2) PackageLicenseDeclared(Package Information)
>3) LicenseID(License Information)
>4) ExtractedText(License Information)
>5) LicenseName(License Information)
> 
> 2. In order to avoid the SPDX_S be polluted in the rebuild, I make
> ${WORKDIR}/${SPDX_TEMP_DIR} to save the source after do_patch.
> 
> 3. In addition, this patch add some more info that meet the SPDX 1.2 Version
> Specification.
> 
> After apply this patch, users only have to add " INHERIT += "spdx" in the
> local.conf file, they can get spdx file that meet the SPDX 1.2 Version
> Specification.
> 
> 
> Cheers
> 
> Lei Maohui
> 
> 
> 
> > -Original Message-
> > From: Lei, Maohui/雷 茂慧
> > Sent: Monday, November 24, 2014 9:49 PM
> > To: openembedded-core@lists.openembedded.org
> > Cc: Lei, Maohui/雷 茂慧
> > Subject: [oe-core][PATCH 1/2] spdx: Provide spdx file that meet SPDX
> > 1.2 Version Specification
> >
> > Signed-off-by: leimaohui 
> > ---
> >  meta/classes/spdx.bbclass | 427
> > --
> >  1 file changed, 150 insertions(+), 277 deletions(-)
> >
> > diff --git a/meta/classes/spdx.bbclass b/meta/classes/spdx.bbclass
> > index
> > 454c53e..9f0f120 100644
> > --- a/meta/classes/spdx.bbclass
> > +++ b/meta/classes/spdx.bbclass
> > @@ -15,178 +15,179 @@
> >  # SPDX file will be output to the path which is defined
> > as[SPDX_MANIFEST_DIR] # in ./meta/conf/licenses.conf.
> >
> > +SPDXOUTPUTDIR = "${WORKDIR}/spdx_output_dir"
> >  SPDXSSTATEDIR = "${WORKDIR}/spdx_sstate_dir"
> >
> >  # If ${S} isn't actually the top-level source directory, set SPDX_S
> > to point at  # the real top-level directory.
> > +
> >  SPDX_S ?= "${S}"
> >
> >  python do_spdx () {
> >  import os, sys
> > -import json, shutil
> > +import json
> >
> >  info = {}
> >  info['workdir'] = d.getVar('WORKDIR', True)
> > -info['sourcedir'] = d.getVar('SPDX_S', True)
> > -info['pn'] = d.getVar('PN', True)
> > -info['pv'] = d.getVar('PV', True)
> > +info['pn'] = d.getVar( 'PN', True )
> > +info['pv'] = d.getVar( 'PV', True )
> > +info['package_download_location'] = d.getVar( 'SRC_URI', True
> > + ).split()[0]
> >  info['spdx_version'] = d.getVar('SPDX_VERSION', True)
> >  info['data_license'] = d.getVar('DATA_LICENSE', True)
> > +info['creator'] = {}
> > +info['creator']['Tool'] = d.getVar('CREATOR_TOOL', True)
> > +info['license_list_version'] = d.getVar('LICENSELISTVERSION', True)
> > +info['package_homepage'] = d.getVar('HOMEPAGE', True)
> > +info['package_summary'] = d.getVar('SUMMARY', True)
> >
> > -sstatedir = d.getVar('SPDXSSTATEDIR', True)
> > -sstatefile = os.path.join(sstatedir, info['pn'] + info['pv'] + ".spdx")
> > -
> > +spdx_sstate_dir = d.getVar('SPDXSSTATEDIR', True)
> >  manifest_dir = d.getVar('SPDX_MANIFEST_DIR', True)
> >  info['outfile'] = os.path.join(manifest_dir, info['pn'] + ".spdx"
> > )
> > -
> > -info['spdx_temp_dir'] = d.getVar('SPDX_TEMP_DIR', True)
> > -info['tar_file'] = os.path.join(info['workdir'], info['pn'] +
> > ".tar.gz" )
> > -
> > +sstatefile = os.path.join(spdx_sstate_dir,
> > +info['pn'] + info['pv'] + ".spdx" )
> > +info['tar_file'] = os.path.join( info['workdir'], info['pn'] +
> > + ".tar.gz" )
> > +
> >  # Make sure important dirs exist
> >  try:
> >  bb.utils.mkdirhier(manifest_dir)
> > -bb.utils.mkdirhier(sstatedir)
> > -bb.utils.mkdirhier(info['spdx_temp_dir'])
> > +bb.utils.mkdirhier(spdx_sstate_dir)
> 

Re: [OE-core] [WIP][PATCH] systemd: don't move libgudev around, it breaks libgudev-1.0.la

[Ash Charles]

I cherry-picked this patch onto dizzy and it unbroke my build.  Is it
possible/reasonable for it to be included in dizzy?
--Ash

On Fri, Oct 31, 2014 at 1:21 AM, Andreas Müller
 wrote:
> On Fri, Oct 24, 2014 at 12:29 PM, Burton, Ross  wrote:
>>
>> On 24 October 2014 10:04, Martin Jansa  wrote:
>>>
>>> Should I resend without WIP tag now when ChenQi confirmed that moving
>>> libgudev isn't needed?
>>
>>
>> No need, I've merged it into my staging branch already.
>>
> This should go into dizzy - right?
>
> Andreas
> --
> ___
> 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: modified option-groups.h generation

[Juro Bystricky]

option-groups.h only explicitely #defines options that are enabled.
EGLIBC options are typically pre-processed under the assumption that if
an option is not explicitely defined then it evaluates as 0.
This assumption is correct, but it generates a compiler warning
message each time an undefined symbol is being evaluated.
In order to remove the warnings, each EGLIBC option is now defined
as 1 if the option is enabled or as 0 otherwise.
The consequence is we cannot use #ifdef OPTION_XXX when evaluating
the option, we must always use #if OPTION_XXX.

[YOCTO #7001]

Signed-off-by: Juro Bystricky 
---
 .../glibc/glibc/eglibc-use-option-groups.patch | 34 +++---
 meta/recipes-core/glibc/glibc/option-groups.patch  |  6 ++--
 2 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/meta/recipes-core/glibc/glibc/eglibc-use-option-groups.patch 
b/meta/recipes-core/glibc/glibc/eglibc-use-option-groups.patch
index 40c7832..7136253 100644
--- a/meta/recipes-core/glibc/glibc/eglibc-use-option-groups.patch
+++ b/meta/recipes-core/glibc/glibc/eglibc-use-option-groups.patch
@@ -5724,7 +5724,7 @@ Index: git/posix/regex.h
  # define RE_INVALID_INTERVAL_ORD (RE_DEBUG << 1)
  
 +/* EGLIBC: Old regex implementation does not support these.  */
-+# ifdef __OPTION_POSIX_REGEXP_GLIBC
++# if __OPTION_POSIX_REGEXP_GLIBC
  /* If this bit is set, then ignore case when matching.
 If not set, then case is significant.  */
  # define RE_ICASE (RE_INVALID_INTERVAL_ORD << 1)
@@ -5740,7 +5740,7 @@ Index: git/posix/regex.h
(RE_CHAR_CLASSES | RE_DOT_NEWLINE  | RE_DOT_NOT_NULL\
 | RE_INTERVALS  | RE_NO_EMPTY_RANGES)
  
-+#ifdef __OPTION_POSIX_REGEXP_GLIBC
++#if __OPTION_POSIX_REGEXP_GLIBC
  #define RE_SYNTAX_POSIX_BASIC \
(_RE_SYNTAX_POSIX_COMMON | RE_BK_PLUS_QM | RE_CONTEXT_INVALID_DUP)
 +#else
@@ -5754,7 +5754,7 @@ Index: git/posix/regex.h
  /* Like REG_NOTBOL, except for the end-of-line.  */
  #define REG_NOTEOL (1 << 1)
  
-+#ifdef __OPTION_POSIX_REGEXP_GLIBC
++#if __OPTION_POSIX_REGEXP_GLIBC
  /* Use PMATCH[0] to delimit the start and end of the search in the
 buffer.  */
  #define REG_STARTEND (1 << 2)
@@ -15542,7 +15542,7 @@ Index: git/sysdeps/ieee754/ldbl-opt/nldbl-compat.c
  libc_hidden_proto (__nldbl___isoc99_vsscanf)
  libc_hidden_proto (__nldbl___isoc99_vfscanf)
 +
-+#ifdef __OPTION_POSIX_WIDE_CHAR_DEVICE_IO
++#if __OPTION_POSIX_WIDE_CHAR_DEVICE_IO
 +libc_hidden_proto (__nldbl_vfwscanf)
 +libc_hidden_proto (__nldbl_vswscanf)
 +libc_hidden_proto (__nldbl_vfwprintf)
@@ -15559,7 +15559,7 @@ Index: git/sysdeps/ieee754/ldbl-opt/nldbl-compat.c
  }
  weak_alias (__nldbl_fprintf, __nldbl__IO_fprintf)
  
-+#ifdef __OPTION_POSIX_WIDE_CHAR_DEVICE_IO
++#if __OPTION_POSIX_WIDE_CHAR_DEVICE_IO
  int
  attribute_compat_text_section weak_function
  __nldbl_fwprintf (FILE *stream, const wchar_t *fmt, ...)
@@ -15575,7 +15575,7 @@ Index: git/sysdeps/ieee754/ldbl-opt/nldbl-compat.c
return done;
  }
  
-+#ifdef __OPTION_POSIX_WIDE_CHAR_DEVICE_IO
++#if __OPTION_POSIX_WIDE_CHAR_DEVICE_IO
  int
  attribute_compat_text_section
  __nldbl_swprintf (wchar_t *s, size_t n, const wchar_t *fmt, ...)
@@ -15591,7 +15591,7 @@ Index: git/sysdeps/ieee754/ldbl-opt/nldbl-compat.c
  }
  libc_hidden_def (__nldbl_vdprintf)
  
-+#ifdef __OPTION_POSIX_WIDE_CHAR_DEVICE_IO
++#if __OPTION_POSIX_WIDE_CHAR_DEVICE_IO
  int
  attribute_compat_text_section weak_function
  __nldbl_vfwprintf (FILE *s, const wchar_t *fmt, va_list ap)
@@ -15607,7 +15607,7 @@ Index: git/sysdeps/ieee754/ldbl-opt/nldbl-compat.c
  libc_hidden_def (__nldbl_vsnprintf)
  weak_alias (__nldbl_vsnprintf, __nldbl___vsnprintf)
  
-+#ifdef __OPTION_POSIX_WIDE_CHAR_DEVICE_IO
++#if __OPTION_POSIX_WIDE_CHAR_DEVICE_IO
  int
  attribute_compat_text_section weak_function
  __nldbl_vswprintf (wchar_t *string, size_t maxlen, const wchar_t *fmt,
@@ -15623,7 +15623,7 @@ Index: git/sysdeps/ieee754/ldbl-opt/nldbl-compat.c
return done;
  }
  
-+#ifdef __OPTION_POSIX_WIDE_CHAR_DEVICE_IO
++#if __OPTION_POSIX_WIDE_CHAR_DEVICE_IO
  int
  attribute_compat_text_section
  __nldbl_vfwscanf (FILE *s, const wchar_t *fmt, va_list ap)
@@ -15639,7 +15639,7 @@ Index: git/sysdeps/ieee754/ldbl-opt/nldbl-compat.c
return done;
  }
  
-+#ifdef __OPTION_POSIX_WIDE_CHAR_DEVICE_IO
++#if __OPTION_POSIX_WIDE_CHAR_DEVICE_IO
  int
  attribute_compat_text_section
  __nldbl___fwprintf_chk (FILE *stream, int flag, const wchar_t *fmt, ...)
@@ -15655,7 +15655,7 @@ Index: git/sysdeps/ieee754/ldbl-opt/nldbl-compat.c
return done;
  }
  
-+#ifdef __OPTION_POSIX_WIDE_CHAR_DEVICE_IO
++#if __OPTION_POSIX_WIDE_CHAR_DEVICE_IO
  int
  attribute_compat_text_section
  __nldbl___swprintf_chk (wchar_t *s, size_t n, int flag, size_t slen,
@@ -15671,7 +15671,7 @@ Index: git/sysdeps/ieee754/ldbl-opt/nldbl-compat.c
  }
  libc_hidden_def (__nldbl___vfprintf_chk)
  
-+#ifdef __OPTION_POSIX_WIDE_CHAR_DEVICE_IO
++#if __OPTION_POSIX_WIDE_CHAR_DEVICE_IO
  int
  attrib

Re: [OE-core] [PATCH] Yocto: Install full set of python modules in Qt SDK toolchain

[Laszlo Papp]

What is the situation on this front?

On Sun, Sep 21, 2014 at 5:02 PM, Marek Vasut  wrote:
> On Friday, September 19, 2014 at 09:25:12 AM, Richard Purdie wrote:
> [...]
>> > git grep nativesdk-python-modules doesn't show any matches in
>> > git://git.yoctoproject.org/poky master . Do you mean the
>> > nativesdk-packagegroup- python I crafted or do you refer to something
>> > else please ?
>> >
>> > Also, shouldn't full python be installed into all the SDK toolchains ? I
>> > am for example unable to compile U-Boot 2014.10rc with the Yocto SDK
>> > toolchain anymore. The SDK is missing python modules and I cannot easily
>> > override the usage of python from the SDK . So I agree with Laszlo here,
>> > the SDK toolchain is somewhat unusable as it is.
>>
>> I refer to the package I mentioned:
>>
>> $ ls -la tmp/deploy/ipk/x86_64-nativesdk/nativesdk-python-modules*
>> -rw-r--r-- 2 richard richard 1512 Sep 18 17:09
>> tmp/deploy/ipk/x86_64-nativesdk/nativesdk-python-modules_2.7.3-r0.3.24_x86
>> _64-nativesdk.ipk
>>
>> See ${PN}-modules defined in python-2.7-manifest.inc.
>
> Oh I see, sorry. Is there any way to look up packages with bitbake or Yocto
> please ?
>
>> I agreed there is a problem, I disagree somewhat about how it should be
>> fixed since you're just installing a set of modules which is defined as
>> those needed to run bitbake and I don't think this is what you actually
>> want. There is also the question of whether nativesdk-python should even
>> be in there...
>
> So would this patch (paste below) work please ? If so, I would submit proper.
>
> diff --git a/meta/classes/populate_sdk_base.bbclass
> b/meta/classes/populate_sdk_base.bbclass
> index 10d04ed..7245d53 100644
> --- a/meta/classes/populate_sdk_base.bbclass
> +++ b/meta/classes/populate_sdk_base.bbclass
> @@ -30,7 +30,11 @@ B_task-populate-sdk = "${SDK_DIR}"
>
>  SDKTARGETSYSROOT = "${SDKPATH}/sysroots/${REAL_MULTIMACH_TARGET_SYS}"
>
> -TOOLCHAIN_HOST_TASK ?= "nativesdk-packagegroup-sdk-host packagegroup-cross-
> canadian-${MACHINE}"
> +TOOLCHAIN_HOST_TASK ?= "   \
> +   nativesdk-packagegroup-sdk-host \
> +   packagegroup-cross-canadian-${MACHINE}  \
> +   nativesdk-python-modules\
> +   "
>  TOOLCHAIN_HOST_TASK_ATTEMPTONLY ?= ""
>  TOOLCHAIN_TARGET_TASK ?= "packagegroup-core-standalone-sdk-target 
> packagegroup-
> core-standalone-sdk-target-dbg"
>  TOOLCHAIN_TARGET_TASK_ATTEMPTONLY ?= ""
> diff --git a/meta/recipes-qt/meta/meta-toolchain-qt.inc b/meta/recipes-
> qt/meta/meta-toolchain-qt.inc
> index 6b162bd..473a123 100644
> --- a/meta/recipes-qt/meta/meta-toolchain-qt.inc
> +++ b/meta/recipes-qt/meta/meta-toolchain-qt.inc
> @@ -1,4 +1,8 @@
> -TOOLCHAIN_HOST_TASK = "nativesdk-packagegroup-${QTNAME}-toolchain-host
> packagegroup-cross-canadian-${MACHINE}"
> +TOOLCHAIN_HOST_TASK = "\
> +   nativesdk-packagegroup-${QTNAME}-toolchain-host \
> +   packagegroup-cross-canadian-${MACHINE}  \
> +   nativesdk-python-modules\
> +   "
>  TOOLCHAIN_TARGET_TASK = "packagegroup-${QTNAME}-toolchain-target"
>  TOOLCHAIN_OUTPUTNAME = "${SDK_NAME}-toolchain-${QTNAME}-${DISTRO_VERSION}"
>
>
> Best regards,
> Marek Vasut
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] ptest-runner: return 1 instead of zero if any test fails

[Laszlo Papp]

On Thu, Nov 27, 2014 at 6:02 PM, Burton, Ross  wrote:
>
> On 27 November 2014 at 17:53, Laszlo Papp  wrote:
>>
>> Ping. I have not received a reply for about three months now? What is
>> the problem?
>
>
> http://git.openembedded.org/openembedded-core/commit/?id=d6b1c9e7e29aaa8d71ccb485b7a88863a117a8b1

Thanks.

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

Re: [OE-core] Adding cgdb to meta

[Laszlo Papp]

Heh, I apparently inspired Ben who three days later added cgdb native
to meta-oe. Now, I gained enough motivation to retry this contribution
thing. Should I submit my cross version? We cannot use the native
variant due to our limited embedded system.

Martin, can you advise, please?

On Tue, Aug 12, 2014 at 4:56 PM, Laszlo Papp  wrote:
> On Tue, Aug 12, 2014 at 4:55 PM, Laszlo Papp  wrote:
>>
>> On Tue, Aug 12, 2014 at 4:51 PM, Laszlo Papp  wrote:
>>>
>>> On Tue, Aug 12, 2014 at 4:48 PM, Burton, Ross 
>>> wrote:

 On 12 August 2014 16:46, Laszlo Papp  wrote:
 > That layer is too big. It is nearly everything that is rejected from
 > meta;
 > ok there are some dedicated layers, like meta-networking, but it feels
 > like
 > the last resort shelter where everything can just be thrown at.
 >
 > I do not think it is just us who do not wanna pull it into their
 > project.
 > Never mind, it remains to be a feature in our layer, which is closed
 > source,
 > then. It is a pity, but I will move along.

 People who think its too big are welcome to copy recipes out of it and
 sync them manually - that's still better than not sharing the recipe.
>>>
>>>
>>> I am unfortunately not interested in participating to something that I
>>> have no intent to even test myself before submitting. meta-oe became a
>>> monster can which I personally would not like to deal with. That is said
>>> with due-respect. If its goal were reconsidered and split into several small
>>> layers, then mayhaps... But it is not there, and I am not sure if it was any
>>> soon...
>>>
>>> Unfortunately, this feature remains proprietary at the point of writing
>>> this. As long as it works for me, I will not be too much bothered, although
>>> I feel sorry for those who will need to reinvent the recipe, modulo
>>> stabilization.
>>
>>
>> But that is alright as long as everyone else finds the IMHO cumbersome
>> workflow with gdb OK for debugging. I think pleasant debugging is very
>> important for developers, and cgdb is still a command line based tool,
>> basically a thing wrapper on top of gdb with ncurses. It is not like "ddd"
>> and other heavy tools. That is why I thought with minor addition, meta could
>> be increase the software development experience; gdb is just way too raw to
>> be effective. But again, no one else might share this opinion, so let us
>> move on.
>>
>> Here is a reminder screenshot for those who do not know it, just in case:
>> http://cgdb.github.io/images/screenshot_debugging.png
>
>
> Alternatively, feel free to advise any sufficient debugging experience with
> oe-core. I will happily switch to any opportunities that reach this level.
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] ptest-runner: return 1 instead of zero if any test fails

[Burton, Ross]

On 27 November 2014 at 17:53, Laszlo Papp  wrote:

> Ping. I have not received a reply for about three months now? What is
> the problem?
>

http://git.openembedded.org/openembedded-core/commit/?id=d6b1c9e7e29aaa8d71ccb485b7a88863a117a8b1

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

Re: [OE-core] [PATCH] ptest-runner: return 1 instead of zero if any test fails

[Laszlo Papp]

Ping. I have not received a reply for about three months now? What is
the problem?

On Fri, Aug 29, 2014 at 11:54 AM, Laszlo Papp  wrote:
> On Mon, Aug 25, 2014 at 7:42 AM, Stoicescu, CorneliuX
>  wrote:
>> Hello,
>>
>> From my experience with ptest, there will always be a few tests failing, so 
>> we will always get exit code 1.
>
> Ptest is not only about meta-core, you need to remember that. My use
> case is actually quite different: running ptest only on my binaries,
> and I will trust the rest of the system. For me, it is critical to see
> if there is any issues in my system. This patch resolves that use
> case, but even for Yocto, you really oughta aim for fixing your tests,
> either with "known failure" or correct means.
>
>> Should this better return exit code 0 if the individual tests performed 
>> correctly(weather they passed or failed) and 1 if there were any errors 
>> during the running of the tests?
>
> I do not understand this question. This is what the current change tries to 
> do.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCHv3] toolchain-script: Add support for ccache builds with the SDK

[Laszlo Papp]

It is necessary to have an SDK for developers who build their software with
ccache to speed up the compilation. Without resolving this, unfortunately the
compilation will fail for them.

Signed-off-by: Laszlo Papp 
---
 meta/classes/toolchain-scripts.bbclass | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/classes/toolchain-scripts.bbclass 
b/meta/classes/toolchain-scripts.bbclass
index d5b9675..9836db4 100644
--- a/meta/classes/toolchain-scripts.bbclass
+++ b/meta/classes/toolchain-scripts.bbclass
@@ -19,6 +19,7 @@ toolchain_create_sdk_env_script () {

EXTRAPATH="$EXTRAPATH:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_ARCH}${TARGET_VENDOR}-$i"
done
echo 'export 
PATH=${SDKPATHNATIVE}${bindir_nativesdk}:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_SYS}'$EXTRAPATH':$PATH'
 >> $script
+   echo 'export 
CCACHE_PATH=${SDKPATHNATIVE}${bindir_nativesdk}:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_SYS}'$EXTRAPATH':$CCACHE_PATH'
 >> $script
echo 'export PKG_CONFIG_SYSROOT_DIR=$SDKTARGETSYSROOT' >> $script
echo 'export PKG_CONFIG_PATH=$SDKTARGETSYSROOT'"$libdir"'/pkgconfig' >> 
$script
echo 'export 
CONFIG_SITE=${SDKPATH}/site-config-'"${multimach_target_sys}" >> $script
@@ -37,6 +38,7 @@ toolchain_create_tree_env_script () {
rm -f $script
touch $script
echo 'export PATH=${STAGING_DIR_NATIVE}/usr/bin:${PATH}' >> $script
+   echo 'export CCACHE_PATH=${STAGING_DIR_NATIVE}/usr/bin:${CCACHE_PATH}' 
>> $script
echo 'export PKG_CONFIG_SYSROOT_DIR=${PKG_CONFIG_SYSROOT_DIR}' >> 
$script
echo 'export PKG_CONFIG_PATH=${PKG_CONFIG_PATH}' >> $script
echo 'export CONFIG_SITE="${@siteinfo_get_files(d)}"' >> $script
-- 
2.1.3

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

[OE-core] [PATCHv2] toolchain-script: Add support for ccache builds with the SDK

[Laszlo Papp]

From: Laszlo Papp 

It is necessary to have an SDK for developers who build their software with
ccache to speed up the compilation. Without resolving this, unfortunately the
compilation will fail for them.

Signed-off-by: Laszlo Papp 
---
 meta/classes/toolchain-scripts.bbclass | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/classes/toolchain-scripts.bbclass 
b/meta/classes/toolchain-scripts.bbclass
index d5b9675..9836db4 100644
--- a/meta/classes/toolchain-scripts.bbclass
+++ b/meta/classes/toolchain-scripts.bbclass
@@ -19,6 +19,7 @@ toolchain_create_sdk_env_script () {

EXTRAPATH="$EXTRAPATH:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_ARCH}${TARGET_VENDOR}-$i"
done
echo 'export 
PATH=${SDKPATHNATIVE}${bindir_nativesdk}:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_SYS}'$EXTRAPATH':$PATH'
 >> $script
+   echo 'export 
CCACHE_PATH=${SDKPATHNATIVE}${bindir_nativesdk}:${SDKPATHNATIVE}${bindir_nativesdk}/${TARGET_SYS}'$EXTRAPATH':$CCACHE_PATH'
 >> $script
echo 'export PKG_CONFIG_SYSROOT_DIR=$SDKTARGETSYSROOT' >> $script
echo 'export PKG_CONFIG_PATH=$SDKTARGETSYSROOT'"$libdir"'/pkgconfig' >> 
$script
echo 'export 
CONFIG_SITE=${SDKPATH}/site-config-'"${multimach_target_sys}" >> $script
@@ -37,6 +38,7 @@ toolchain_create_tree_env_script () {
rm -f $script
touch $script
echo 'export PATH=${STAGING_DIR_NATIVE}/usr/bin:${PATH}' >> $script
+   echo 'export CCACHE_PATH=${STAGING_DIR_NATIVE}/usr/bin:${CCACHE_PATH}' 
>> $script
echo 'export PKG_CONFIG_SYSROOT_DIR=${PKG_CONFIG_SYSROOT_DIR}' >> 
$script
echo 'export PKG_CONFIG_PATH=${PKG_CONFIG_PATH}' >> $script
echo 'export CONFIG_SITE="${@siteinfo_get_files(d)}"' >> $script
-- 
2.1.3

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

[OE-core] [BUG] Openssh not closing connections on service stop

[Diego]

Hi all,

I'd like to share with you what I consider a bug.

I've generally noticed in my Linux experience that I get automatically 
disconnected from an ssh session if the ssh host gets shutdown or rebooted 
with the message:
Connection to x.y.w.z closed by remote host.
Connection to x.y.w.z closed.

This doesn't seem to happen on my OSes built on core-image-minimal with 
openssh support.

Moreover I noticed that if I stop the ssh service:
# /etc/init.d/sshd stop
my ssh connections don't get dropped, I can continue using ssh session like 
nothing happened. I can even see the connection process still up and running:
# ps | grep ssh
 1790 root  4568 S/usr/sbin/sshd
 1848 root  4852 Ssshd: root@pts/0
 1886 root  2896 Sgrep ssh
# /etc/init.d/sshd stop
Stopping OpenBSD Secure Shell server: sshdstopped /usr/sbin/sshd (pid 1790)
.
# ps | grep ssh
 1848 root  4852 Ssshd: root@pts/0
 1894 root  2892 Sgrep ssh

Isn't service termination supposed to stop all related connections at the same 
time? Can anybody else reproduce (or not) this issue?

Bests,
Diego

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

[OE-core] [PATCH 1/1] toaster.bbclass: use the openembedded-core name

[Alex DAMIAN]

From: Alexandru DAMIAN 

Fixing the bug where the openembedded-core name was registered
as "meta" in toaster.

[YOCTO #6962]

Signed-off-by: Alexandru DAMIAN 
---
 meta/classes/toaster.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/toaster.bbclass b/meta/classes/toaster.bbclass
index 1525317..a7dd0aa 100644
--- a/meta/classes/toaster.bbclass
+++ b/meta/classes/toaster.bbclass
@@ -71,7 +71,7 @@ python toaster_layerinfo_dumpdata() {
 layer_url = 'http://layers.openembedded.org/layerindex/layer/{layer}/'
 layer_url_name = _get_url_map_name(layer_name)
 
-layer_info['name'] = layer_name
+layer_info['name'] = layer_url_name
 layer_info['local_path'] = layer_path
 layer_info['layer_index_url'] = layer_url.format(layer=layer_url_name)
 layer_info['version'] = _get_layer_version_information(layer_path)
-- 
1.9.1

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

[OE-core] [PATCH 1/1] toaster: naming and description changes

[Alex DAMIAN]

From: Belen Barros Pena 

Some minor changes to the names and descriptions
used in the Toaster configuration file:

* Change the name of the local layer source from Local OE-Core
to Local OpenEmbedded

* Change the imported layer source name from User Imported Layers
to just Imported layers. It is shorter, which helps table display

* Change the description of the master release from OE-Core
master to OpenEmbedded master

* Change the description of the dizzy release from OE-Core dizzy
to OpenEmbedded Dizzy

* Change the helptext of the dizzy release to remove the
"latest" reference, which can make maintenance hard

* Change the name of the Local Yocto Project release to Local
OpenEmbedded

Signed-off-by: Belen Barros Pena 

diff --git a/meta/conf/toasterconf.json b/meta/conf/toasterconf.json
index c9835d0..fe1564e 100644
--- a/meta/conf/toasterconf.json
+++ b/meta/conf/toasterconf.json
@@ -2,7 +2,7 @@
 "config": {"MACHINE": "qemux86", "DISTRO": "poky"},
 "layersources": [
 {
-"name": "Local OE-Core",
+"name": "Local OpenEmbedded",
 "sourcetype": "local",
 "apiurl": "../../",
 "branches": ["HEAD", "master", "dizzy"],
@@ -22,7 +22,7 @@
 "branches": ["master", "dizzy"]
 },
 {
-"name": "User Imported Layers",
+"name": "Imported layers",
 "sourcetype": "imported",
 "apiurl": "",
 "branches": ["master", "dizzy", "HEAD"]
@@ -55,30 +55,30 @@
 "releases": [
 {
 "name": "master",
-"description": "OE-Core master",
+"description": "OpenEmbedded master",
 "bitbake": "master",
 "branch": "master",
 "defaultlayers": [ "openembedded-core" ],
-"layersourcepriority": { "User Imported Layers": 99, "Local 
OE-Core" : 10, "OpenEmbedded" :  0 },
+"layersourcepriority": { "Imported layers": 99, "Local 
OpenEmbedded" : 10, "OpenEmbedded" :  0 },
 "helptext": "Toaster will run your builds using the OpenEmbedded 
master branch, where active development takes place. This is not a stable 
branch, so your builds might not work as expected."
 },
 {
 "name": "dizzy",
-"description": "OE-Core dizzy",
+"description": "OpenEmbedded Dizzy",
 "bitbake": "dizzy",
 "branch": "dizzy",
 "defaultlayers": [ "openembedded-core" ],
-"layersourcepriority": { "User Imported Layers": 99, "Local 
OE-Core" : 10, "OpenEmbedded" :  0 },
-"helptext": "Toaster will run your builds with the latest 
OpenEmbedded release, the dizzy branch."
+"layersourcepriority": { "Imported layers": 99, "Local 
OpenEmbedded" : 10, "OpenEmbedded" :  0 },
+"helptext": "Toaster will run your builds with the OpenEmbedded 
Dizzy release"
 },
 {
 "name": "local",
-"description": "Local Yocto Project",
+"description": "Local OpenEmbedded",
 "bitbake": "HEAD",
 "branch": "HEAD",
 "defaultlayers": [ "openembedded-core" ],
-"layersourcepriority": { "User Imported Layers": 99, "Local 
OE-Core" : 10, "OpenEmbedded" :  0 },
-"helptext": "Toaster will run your builds with the version of the 
OpenEmbedded that you have cloned or downloaded to your computer."
+"layersourcepriority": { "Imported layers": 99, "Local 
OpenEmbedded" : 10, "OpenEmbedded" :  0 },
+"helptext": "Toaster will run your builds with the version of 
OpenEmbedded that you have cloned or downloaded to your computer."
 }
 ]
 }
-- 
1.9.1

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

[OE-core] [PATCH 2/3] image.bbclass: whitespace

[Michael Jones]

Don't mix tabs and spaces
---
 meta/classes/image.bbclass | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index d27abc9..82e977c 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -193,12 +193,12 @@ read_only_rootfs_hook () {
sed -i -e 
'/^[#[:space:]]*\/dev\/root/{s/defaults/ro/;s/\([[:space:]]*[[:digit:]]\)\([[:space:]]*\)[[:digit:]]$/\1\20/}'
 ${IMAGE_ROOTFS}/etc/fstab
 
if ${@bb.utils.contains("DISTRO_FEATURES", "sysvinit", "true", "false", 
d)}; then
-   # Change the value of ROOTFS_READ_ONLY in /etc/default/rcS to 
yes
+   # Change the value of ROOTFS_READ_ONLY in /etc/default/rcS to 
yes
if [ -e ${IMAGE_ROOTFS}/etc/default/rcS ]; then
sed -i 's/ROOTFS_READ_ONLY=no/ROOTFS_READ_ONLY=yes/' 
${IMAGE_ROOTFS}/etc/default/rcS
fi
-   # Run populate-volatile.sh at rootfs time to set up basic files
-   # and directories to support read-only rootfs.
+   # Run populate-volatile.sh at rootfs time to set up basic files
+   # and directories to support read-only rootfs.
if [ -x ${IMAGE_ROOTFS}/etc/init.d/populate-volatile.sh ]; then
${IMAGE_ROOTFS}/etc/init.d/populate-volatile.sh
fi
-- 
1.9.1


MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Uwe Furtner, Erhard Meier
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/3] image.bbclass: remove comment that readonly only works for sysvinit

[Michael Jones]

Should have been removed with
92f956d tweak read_only_rootfs_hook to also support systemd based systems
---
 meta/classes/image.bbclass | 1 -
 1 file changed, 1 deletion(-)

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 6bbfaf8..d27abc9 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -188,7 +188,6 @@ do_rootfs[cleandirs] += "${S}"
 do_rootfs[umask] = "022"
 
 # A hook function to support read-only-rootfs IMAGE_FEATURES
-# Currently, it only supports sysvinit system.
 read_only_rootfs_hook () {
# Tweak the mount option and fs_passno for rootfs in fstab
sed -i -e 
'/^[#[:space:]]*\/dev\/root/{s/defaults/ro/;s/\([[:space:]]*[[:digit:]]\)\([[:space:]]*\)[[:digit:]]$/\1\20/}'
 ${IMAGE_ROOTFS}/etc/fstab
-- 
1.9.1


MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Uwe Furtner, Erhard Meier
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 3/3] image.bbclass: keep fstab pretty when swapping 'ro' for defaults

[Michael Jones]

Keep the columns in fstab lined up when rootfs is read-only
---
 meta/classes/image.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 82e977c..ae1431e 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -190,7 +190,7 @@ do_rootfs[umask] = "022"
 # A hook function to support read-only-rootfs IMAGE_FEATURES
 read_only_rootfs_hook () {
# Tweak the mount option and fs_passno for rootfs in fstab
-   sed -i -e 
'/^[#[:space:]]*\/dev\/root/{s/defaults/ro/;s/\([[:space:]]*[[:digit:]]\)\([[:space:]]*\)[[:digit:]]$/\1\20/}'
 ${IMAGE_ROOTFS}/etc/fstab
+   sed -i -e '/^[#[:space:]]*\/dev\/root/{s/defaults/ro  
/;s/\([[:space:]]*[[:digit:]]\)\([[:space:]]*\)[[:digit:]]$/\1\20/}' 
${IMAGE_ROOTFS}/etc/fstab
 
if ${@bb.utils.contains("DISTRO_FEATURES", "sysvinit", "true", "false", 
d)}; then
# Change the value of ROOTFS_READ_ONLY in /etc/default/rcS to 
yes
-- 
1.9.1


MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Uwe Furtner, Erhard Meier
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Deployment for machine X will remove its results from machine Y's deploy dir

[Richard Purdie]

On Thu, 2014-11-27 at 16:17 +0100, Mike Looijmans wrote:
> If I understand correctly, having two "MACHINE" share the same 
> MACHINE_ARCH (which is the case for several intel boards too), is not 
> actually allowed?
> 
> Because you get the same kernel/bootloader for different machines then. 
> That's what I wanted, and that triggered me finding this issue.

Its a very good question. As things stand today, there is a one to one
mapping between MACHINE_ARCH and MACHINE, the difference being the
removal of invalid characters for the package namespace. That implies
that no, its not allowed.

The intel boards you mention do something a little different, they
inject a new "arch" into the hierarchy and then several machines share
that common "arch".

I suspect the intel boards you mention do suffer from the issue you
mention in a related way and the fix may be to s/MACHINE/PACKAGE_ARCH/
in DEPLOY_DIR_IMAGE as previously mentioned. The difference is I suspect
they deploy for the first machine built and then not for any other.
Nitin/Darren may be interested in checking into that.

> Please realize that the example is just an example. The actual problem 
> I'm experiencing is with the kernel and bootloader!

Right, the allarch behaviour is an illustration but not the underlying
problem you need to resolve (although its related).

Cheers,

Richard

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

Re: [OE-core] [PATCH] libxml2: fix CVE-2014-3660

[akuster808]

On 11/27/2014 05:58 AM, Ahsan, Noor wrote:

Hi,

Sorry for the false alarm. It was included in master but not in dizzy branch. 
Kindly include in that branch as well. Thanks.

Sure thing.

thanks for the reminder.

- Armin



Noor

-Original Message-
From: Ahsan, Noor
Sent: Thursday, November 27, 2014 6:45 PM
To: 'Joe MacDonald'; openembedded-core@lists.openembedded.org
Subject: RE: [OE-core] [PATCH] libxml2: fix CVE-2014-3660

Hello,

We sent out this patch but we haven't received any feedback not it was 
included. Kindly include this in dizzy branch.

Thanks.

Noor

-Original Message-
From: openembedded-core-boun...@lists.openembedded.org 
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Joe 
MacDonald
Sent: Monday, October 20, 2014 10:51 PM
To: openembedded-core@lists.openembedded.org
Subject: [OE-core] [PATCH] libxml2: fix CVE-2014-3660

It was discovered that the patch for CVE-2014-0191 for libxml2 is incomplete.  
It is still possible to have libxml2 incorrectly perform entity substituton 
even when the application using libxml2 explicitly disables the feature.  This 
can allow a remote denial-of-service attack on systems with libxml2 prior to 
2.9.2.

References:
 http://www.openwall.com/lists/oss-security/2014/10/17/7
 
https://www.ncsc.nl/actueel/nieuwsberichten/kwetsbaarheid-ontdekt-in-libxml2.html

Signed-off-by: Joe MacDonald 
---
  meta/recipes-core/libxml/libxml2.inc   |   1 +
  .../libxml/libxml2/libxml2-CVE-2014-3660.patch | 147 +
  2 files changed, 148 insertions(+)
  create mode 100644 
meta/recipes-core/libxml/libxml2/libxml2-CVE-2014-3660.patch

diff --git a/meta/recipes-core/libxml/libxml2.inc 
b/meta/recipes-core/libxml/libxml2.inc
index bcf9a62..c729c19 100644
--- a/meta/recipes-core/libxml/libxml2.inc
+++ b/meta/recipes-core/libxml/libxml2.inc
@@ -21,6 +21,7 @@ SRC_URI = 
"ftp://xmlsoft.org/libxml2/libxml2-${PV}.tar.gz;name=libtar \
 file://libxml2-CVE-2014-0191-fix.patch \
 file://python-sitepackages-dir.patch \
 file://libxml-m4-use-pkgconfig.patch \
+   file://libxml2-CVE-2014-3660.patch \
"

  BINCONFIG = "${bindir}/xml2-config"
diff --git a/meta/recipes-core/libxml/libxml2/libxml2-CVE-2014-3660.patch 
b/meta/recipes-core/libxml/libxml2/libxml2-CVE-2014-3660.patch
new file mode 100644
index 000..b9621c9
--- /dev/null
+++ b/meta/recipes-core/libxml/libxml2/libxml2-CVE-2014-3660.patch
@@ -0,0 +1,147 @@
+From be2a7edaf289c5da74a4f9ed3a0b6c733e775230 Mon Sep 17 00:00:00 2001
+From: Daniel Veillard 
+Date: Thu, 16 Oct 2014 13:59:47 +0800
+Subject: Fix for CVE-2014-3660
+
+Issues related to the billion laugh entity expansion which happened to
+escape the initial set of fixes
+
+Upstream-status: Backport
+Reference:
+https://git.gnome.org/browse/libxml2/commit/?id=be2a7edaf289c5da74a4f9e
+d3a0b6c733e775230&context=3&ignorews=0&ss=0
+
+Signed-off-by: Joe MacDonald 
+
+diff --git a/parser.c b/parser.c
+index f51e8d2..1d93967 100644
+--- a/parser.c
 b/parser.c
+@@ -130,6 +130,29 @@ xmlParserEntityCheck(xmlParserCtxtPtr ctxt, size_t size,
+ return (0);
+ if (ctxt->lastError.code == XML_ERR_ENTITY_LOOP)
+ return (1);
++
++/*
++ * This may look absurd but is needed to detect
++ * entities problems
++ */
++if ((ent != NULL) && (ent->etype != XML_INTERNAL_PREDEFINED_ENTITY) &&
++  (ent->content != NULL) && (ent->checked == 0)) {
++  unsigned long oldnbent = ctxt->nbentities;
++  xmlChar *rep;
++
++  ent->checked = 1;
++
++  rep = xmlStringDecodeEntities(ctxt, ent->content,
++XML_SUBSTITUTE_REF, 0, 0, 0);
++
++  ent->checked = (ctxt->nbentities - oldnbent + 1) * 2;
++  if (rep != NULL) {
++  if (xmlStrchr(rep, '<'))
++  ent->checked |= 1;
++  xmlFree(rep);
++  rep = NULL;
++  }
++}
+ if (replacement != 0) {
+   if (replacement < XML_MAX_TEXT_LENGTH)
+   return(0);
+@@ -189,9 +212,12 @@ xmlParserEntityCheck(xmlParserCtxtPtr ctxt, size_t size,
+ return (0);
+ } else {
+ /*
+- * strange we got no data for checking just return
++ * strange we got no data for checking
+  */
+-return (0);
++  if (((ctxt->lastError.code != XML_ERR_UNDECLARED_ENTITY) &&
++   (ctxt->lastError.code != XML_WAR_UNDECLARED_ENTITY)) ||
++  (ctxt->nbentities <= 1))
++  return (0);
+ }
+ xmlFatalErr(ctxt, XML_ERR_ENTITY_LOOP, NULL);
+ return (1);
+@@ -2589,6 +2615,7 @@ xmlParserHandlePEReference(xmlParserCtxtPtr ctxt) {
+ name, NULL);
+   ctxt->valid = 0;
+   }
++  xmlParserEntityCheck(ctxt, 0, NULL, 0);
+   } else if (ctxt->input->free != deallocblankswrapper) {
+   input = xmlNewBlanksWrapperInputStream(ctxt, entity);
+  

Re: [OE-core] Deployment for machine X will remove its results from machine Y's deploy dir

[Mike Looijmans]

On 27-11-2014 15:41, Richard Purdie wrote:

On Thu, 2014-11-27 at 15:22 +0100, Mike Looijmans wrote:

On 11/27/2014 02:17 PM, Richard Purdie wrote:

On Thu, 2014-11-27 at 05:02 -0700, Gary Thomas wrote:

On 2014-11-27 01:35, Mike Looijmans wrote:

Here's an example recipe to demonstrate the issue. Save it as "deployme.bb" 
into a recipe dir. Then build it for two machines. Building it for one machine will 
remove it from the
deployment directory of the other. This problem has been bugging me for months, I had 
files just "disappear" mysteriously from the deploy directory and seemingly 
random times, and
now I finally figured out what causes it.

(cut here)

SUMMARY = "Demonstrate a bug in OE deployment"
DESCRIPTION = "Build this package for a machine X, then look at the image's \
deploy directory. You'll see a deployme.txt there. Now build it for another 
\
machine, e.g. "Y". The deployme.txt for machine X will have disappeared \
from the image dir. This appears to be a bug in OE's deployment."
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = 
"file://${COREBASE}/LICENSE;md5=4d92cd373abda3937c2bc47fbc49d690"

inherit allarch deploy

do_compile () {
   echo "Hello world!" > deployme.txt
}

do_deploy () {
   install -d ${DEPLOYDIR}
   install -m 644 ${B}/deployme.txt ${DEPLOYDIR}/
}

addtask deploy before do_build after do_compile

(cut here)


Very interesting & verified with the latest master.

Have you filed a bug?  https://bugzilla.yoctoproject.org/


Well, I'm not convinced this is a bug as such. You've created an
"allarch" deploy task, how would you expect this to behave?

"allarch" means that the output from this task is universal and can be
used on all targets. It will therefore get run once.

A "deploy" task is machine specific.

What ends up happening is therefore the task has a stamp is
"universally" created. When you change machine, the checksum of the task
changes, the previous version is removed, the new version is installed.

So in many ways the system is doing exactly what I would expect it to do
and it isn't a bug in that sense.


It's not a bug in the sense that it doesn't do as it was programmed to do.


Its doing *exactly* what the was designed to do. That doesn't match what
you want/expect though.


  I understand what's happening here.

I just think that the logic here is wrong. If "deploy" is machine specific,
then the implicit "undeploy" should be machine specific too, right?


Well, its more complex than that.

deploy.bbclass defaults to DEPLOY_DIR_IMAGE.

DEPLOY_DIR_IMAGE defaults to ${DEPLOY_DIR}/images/${MACHINE}

I actually put off merging the latter since I knew it would cause
issues, I just couldn't articulate all of them at the time :(.


The real question is how should an "allarch" + "deploy" task behave when
you've specified machine specific paths? Perhaps erroring would be
better?


That would mean that roughly all deploy tasks will fail.


I'm not sure we have many deploy+allarch tasks so I think "roughly none"
would be a better description.

deploy is usually used for bootloaders and kernels, both of which are
not allarch.


At best they're tied
to MACHINE_ARCH, but never to MACHINE itself.


No, they're tried to MACHINE itself, see above.


Would be strange to put PACKAGE_ARCH="${MACHINE}" in a recipe that clearly has
no dependency on machine specific things. And I wrote "${MACHINE}" here on
purpose.


Dropping the "allarch" would be better than that.


I was thinking along the lines of "DEPLOY_DIR_IMAGE must have the same prefix"
or so.

If I knew the solution, I'd have posted a patch instead of a question or report.


Well, allarch.bbclass could override DEPLOY_DIR_IMAGE to remove
the /${MACHINE} suffix. That would appear to fix the issues you're
seeing, at the risk of having a different group of people upset that you
don't get a complete directory per machine.

It comes down to which behaviour we want. Changing MACHINE in the
definition of DEPLOY_DIR_IMAGE to PACKAGE_ARCH might be the better
solution, then it will deploy based on how specific or not specific the
resulting code it. That will likely upset certain people even more
though. The other option is to accept that its machine specific and do
PACKAGE_ARCH="${MACHINE_ARCH}" in the class. That is suboptimal for the
reasons you describe but would get the behaviour some people want.

I suspect there isn't a right answer here :(

An opinion from Martin/Koen might be useful at this point since it could
affect them more than others (as well as things like the yocto project
autobuilder output and output processing/testing/releasing).



If I understand correctly, having two "MACHINE" share the same 
MACHINE_ARCH (which is the case for several intel boards too), is not 
actually allowed?


Because you get the same kernel/bootloader for different machines then. 
That's what I wanted, and that triggered me finding this issue.


Please realize that the example is just an example. The actual problem 
I'm experie

[OE-core] [PATCH] combo-layer: support updating up to arbitrary commit

[Markus Lehtonen]

Support defining the top commit up to which to update. In other words,
this makes it possible to update up to certain point other than the
branch head. The update point (git commitish) is given on the command
line by appending the component name(s) with a colon and the commitish,
e.g.
 $ combo-layer update my_component:sha1

Only the "update" action supports this.

Signed-off-by: Markus Lehtonen 
---
 scripts/combo-layer | 45 +++--
 1 file changed, 27 insertions(+), 18 deletions(-)

diff --git a/scripts/combo-layer b/scripts/combo-layer
index 19d64e6..2f618bf 100755
--- a/scripts/combo-layer
+++ b/scripts/combo-layer
@@ -26,6 +26,7 @@ import logging
 import subprocess
 import ConfigParser
 import re
+from collections import OrderedDict
 
 __version__ = "0.2.1"
 
@@ -305,18 +306,17 @@ def check_rev_branch(component, repodir, rev, branch):
 return False
 return True
 
-def get_repos(conf, args):
+def get_repos(conf, repo_names):
 repos = []
-if len(args) > 1:
-for arg in args[1:]:
-if arg.startswith('-'):
-break
-else:
-repos.append(arg)
-for repo in repos:
-if not repo in conf.repos:
-logger.error("Specified component '%s' not found in 
configuration" % repo)
-sys.exit(0)
+for name in repo_names:
+if name.startswith('-'):
+break
+else:
+repos.append(name)
+for repo in repos:
+if not repo in conf.repos:
+logger.error("Specified component '%s' not found in configuration" 
% repo)
+sys.exit(0)
 
 if not repos:
 repos = conf.repos
@@ -327,7 +327,7 @@ def action_pull(conf, args):
 """
 update the component repos only
 """
-repos = get_repos(conf, args)
+repos = get_repos(conf, args[1:])
 
 # make sure all repos are clean
 for name in repos:
@@ -348,7 +348,13 @@ def action_update(conf, args):
 generate the patch list
 apply the generated patches
 """
-repos = get_repos(conf, args)
+components = [arg.split(':')[0] for arg in args[1:]]
+revisions = []
+for arg in args[1:]:
+revision= arg.split(':', 1)[1] if ':' in arg else None
+revisions.append(revision)
+# Map commitishes to repos
+repos = OrderedDict(zip(get_repos(conf, components), revisions))
 
 # make sure combo repo is clean
 check_repo_clean(os.getcwd())
@@ -362,9 +368,9 @@ def action_update(conf, args):
 if conf.nopull:
 logger.info("Skipping pull (-n)")
 else:
-action_pull(conf, args)
+action_pull(conf, components)
 
-for name in repos:
+for name, revision in repos.iteritems():
 repo = conf.repos[name]
 ldir = repo['local_repo_dir']
 dest_dir = repo['dest_dir']
@@ -373,18 +379,21 @@ def action_update(conf, args):
 
 # Step 2: generate the patch list and store to patch dir
 logger.info("Generating patches from %s..." % name)
+top_revision = revision or branch
+if not check_rev_branch(name, ldir, top_revision, branch):
+sys.exit(1)
 if dest_dir != ".":
 prefix = "--src-prefix=a/%s/ --dst-prefix=b/%s/" % (dest_dir, 
dest_dir)
 else:
 prefix = ""
 if repo['last_revision'] == "":
 logger.info("Warning: last_revision of component %s is not set, 
starting from the first commit" % name)
-patch_cmd_range = "--root %s" % branch
-rev_cmd_range = branch
+patch_cmd_range = "--root %s" % top_revision
+rev_cmd_range = top_revision
 else:
 if not check_rev_branch(name, ldir, repo['last_revision'], branch):
 sys.exit(1)
-patch_cmd_range = "%s..%s" % (repo['last_revision'], branch)
+patch_cmd_range = "%s..%s" % (repo['last_revision'], top_revision)
 rev_cmd_range = patch_cmd_range
 
 file_filter = repo.get('file_filter',"")
-- 
1.8.4.5

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

[OE-core] [PATCH] gcc-4.8: Drop unused patch

[Richard Purdie]

I disabled this patch as it became obsolete some time ago but forgot to 
remove it, this cleans things up.

Signed-off-by: Richard Purdie 

diff --git a/meta/recipes-devtools/gcc/gcc-4.8/0051-fix-unwind-race.patch 
b/meta/recipes-devtools/gcc/gcc-4.8/0051-fix-unwind-race.patch
deleted file mode 100644
index e4fff12..000
--- a/meta/recipes-devtools/gcc/gcc-4.8/0051-fix-unwind-race.patch
+++ /dev/null
@@ -1,33 +0,0 @@
-These is a race over the installation of files into the include/ directory 
between:
-
-| (cd `${PWDCMD-pwd}`/include ; \|  tar -cf - .; exit 0) | (cd 
/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-oecore/build/build/tmp-eglibc/work/armv5te-oe-linux-gnueabi/gcc-cross-initial/4.8.2-r0/image/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-oecore/build/build/tmp-eglibc/sysroots/x86_64-linux/usr/lib/armv5te-oe-linux-gnueabi.gcc-cross-initial/gcc/arm-oe-linux-gnueabi/4.8.2/include;
 tar xpf - )
-
-and
-
-| /bin/install -c -m 644 unwind.h 
/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-oecore/build/build/tmp-eglibc/work/armv5te-oe-linux-gnueabi/gcc-cross-initial/4.8.2-r0/image/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-oecore/build/build/tmp-eglibc/sysroots/x86_64-linux/usr/lib/armv5te-oe-linux-gnueabi.gcc-cross-initial/gcc/arm-oe-linux-gnueabi/4.8.2/include
-| /bin/install: cannot create regular file 
'/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-oecore/build/build/tmp-eglibc/work/armv5te-oe-linux-gnueabi/gcc-cross-initial/4.8.2-r0/image/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-oecore/build/build/tmp-eglibc/sysroots/x86_64-linux/usr/lib/armv5te-oe-linux-gnueabi.gcc-cross-initial/gcc/arm-oe-linux-gnueabi/4.8.2/include/unwind.h':
 File exists
-| make[1]: *** [install-unwind_h] Error 1
-
-which under the right circumstances leads to the above build failure. Since we 
don't 
-need two copies of this file and we don't use install-no-fixincludes, we can 
disable 
-the libgcc installation.
-
-RP 2014/04/10
-
-Upstream-Status: Pending [would need a rewrite into an acceptable patch form]
-
-Index: gcc-4.8.2/libgcc/Makefile.in
-===
 gcc-4.8.2.orig/libgcc/Makefile.in  2013-02-04 19:06:20.0 +
-+++ gcc-4.8.2/libgcc/Makefile.in   2014-04-10 09:58:33.018748787 +
-@@ -1020,8 +1020,8 @@
- # This is however useful for "install-no-fixincludes" case, when only the gcc
- # internal headers are copied by gcc's install.
- install-unwind_h:
--  $(mkinstalldirs) $(DESTDIR)$(libsubdir)/include
--  $(INSTALL_DATA) unwind.h $(DESTDIR)$(libsubdir)/include
-+# $(mkinstalldirs) $(DESTDIR)$(libsubdir)/include
-+# $(INSTALL_DATA) unwind.h $(DESTDIR)$(libsubdir)/include
- 
- all: install-unwind_h-forbuild
- 


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

Re: [OE-core] Deployment for machine X will remove its results from machine Y's deploy dir

[Richard Purdie]

On Thu, 2014-11-27 at 15:22 +0100, Mike Looijmans wrote:
> On 11/27/2014 02:17 PM, Richard Purdie wrote:
> > On Thu, 2014-11-27 at 05:02 -0700, Gary Thomas wrote:
> >> On 2014-11-27 01:35, Mike Looijmans wrote:
> >>> Here's an example recipe to demonstrate the issue. Save it as 
> >>> "deployme.bb" into a recipe dir. Then build it for two machines. Building 
> >>> it for one machine will remove it from the
> >>> deployment directory of the other. This problem has been bugging me for 
> >>> months, I had files just "disappear" mysteriously from the deploy 
> >>> directory and seemingly random times, and
> >>> now I finally figured out what causes it.
> >>>
> >>> (cut here)
> >>>
> >>> SUMMARY = "Demonstrate a bug in OE deployment"
> >>> DESCRIPTION = "Build this package for a machine X, then look at the 
> >>> image's \
> >>>deploy directory. You'll see a deployme.txt there. Now build it for 
> >>> another \
> >>>machine, e.g. "Y". The deployme.txt for machine X will have 
> >>> disappeared \
> >>>from the image dir. This appears to be a bug in OE's deployment."
> >>> LICENSE = "GPLv2"
> >>> LIC_FILES_CHKSUM = 
> >>> "file://${COREBASE}/LICENSE;md5=4d92cd373abda3937c2bc47fbc49d690"
> >>>
> >>> inherit allarch deploy
> >>>
> >>> do_compile () {
> >>>   echo "Hello world!" > deployme.txt
> >>> }
> >>>
> >>> do_deploy () {
> >>>   install -d ${DEPLOYDIR}
> >>>   install -m 644 ${B}/deployme.txt ${DEPLOYDIR}/
> >>> }
> >>>
> >>> addtask deploy before do_build after do_compile
> >>>
> >>> (cut here)
> >>
> >> Very interesting & verified with the latest master.
> >>
> >> Have you filed a bug?  https://bugzilla.yoctoproject.org/
> >
> > Well, I'm not convinced this is a bug as such. You've created an
> > "allarch" deploy task, how would you expect this to behave?
> >
> > "allarch" means that the output from this task is universal and can be
> > used on all targets. It will therefore get run once.
> >
> > A "deploy" task is machine specific.
> >
> > What ends up happening is therefore the task has a stamp is
> > "universally" created. When you change machine, the checksum of the task
> > changes, the previous version is removed, the new version is installed.
> >
> > So in many ways the system is doing exactly what I would expect it to do
> > and it isn't a bug in that sense.
> 
> It's not a bug in the sense that it doesn't do as it was programmed to do.

Its doing *exactly* what the was designed to do. That doesn't match what
you want/expect though.

>  I understand what's happening here.
> 
> I just think that the logic here is wrong. If "deploy" is machine specific, 
> then the implicit "undeploy" should be machine specific too, right?

Well, its more complex than that.

deploy.bbclass defaults to DEPLOY_DIR_IMAGE.

DEPLOY_DIR_IMAGE defaults to ${DEPLOY_DIR}/images/${MACHINE} 

I actually put off merging the latter since I knew it would cause
issues, I just couldn't articulate all of them at the time :(.

> > The real question is how should an "allarch" + "deploy" task behave when
> > you've specified machine specific paths? Perhaps erroring would be
> > better?
> 
> That would mean that roughly all deploy tasks will fail.

I'm not sure we have many deploy+allarch tasks so I think "roughly none"
would be a better description.

deploy is usually used for bootloaders and kernels, both of which are
not allarch.

> At best they're tied 
> to MACHINE_ARCH, but never to MACHINE itself.

No, they're tried to MACHINE itself, see above.

> Would be strange to put PACKAGE_ARCH="${MACHINE}" in a recipe that clearly 
> has 
> no dependency on machine specific things. And I wrote "${MACHINE}" here on 
> purpose.

Dropping the "allarch" would be better than that.

> I was thinking along the lines of "DEPLOY_DIR_IMAGE must have the same 
> prefix" 
> or so.
> 
> If I knew the solution, I'd have posted a patch instead of a question or 
> report.

Well, allarch.bbclass could override DEPLOY_DIR_IMAGE to remove
the /${MACHINE} suffix. That would appear to fix the issues you're
seeing, at the risk of having a different group of people upset that you
don't get a complete directory per machine.

It comes down to which behaviour we want. Changing MACHINE in the
definition of DEPLOY_DIR_IMAGE to PACKAGE_ARCH might be the better
solution, then it will deploy based on how specific or not specific the
resulting code it. That will likely upset certain people even more
though. The other option is to accept that its machine specific and do
PACKAGE_ARCH="${MACHINE_ARCH}" in the class. That is suboptimal for the
reasons you describe but would get the behaviour some people want.

I suspect there isn't a right answer here :(

An opinion from Martin/Koen might be useful at this point since it could
affect them more than others (as well as things like the yocto project
autobuilder output and output processing/testing/releasing).

Cheers,

Richard



-- 
___
Openembedded-core mail

Re: [OE-core] Deployment for machine X will remove its results from machine Y's deploy dir

[Mike Looijmans]

On 11/27/2014 02:17 PM, Richard Purdie wrote:

On Thu, 2014-11-27 at 05:02 -0700, Gary Thomas wrote:

On 2014-11-27 01:35, Mike Looijmans wrote:

Here's an example recipe to demonstrate the issue. Save it as "deployme.bb" 
into a recipe dir. Then build it for two machines. Building it for one machine will 
remove it from the
deployment directory of the other. This problem has been bugging me for months, I had 
files just "disappear" mysteriously from the deploy directory and seemingly 
random times, and
now I finally figured out what causes it.

(cut here)

SUMMARY = "Demonstrate a bug in OE deployment"
DESCRIPTION = "Build this package for a machine X, then look at the image's \
   deploy directory. You'll see a deployme.txt there. Now build it for another \
   machine, e.g. "Y". The deployme.txt for machine X will have disappeared \
   from the image dir. This appears to be a bug in OE's deployment."
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = 
"file://${COREBASE}/LICENSE;md5=4d92cd373abda3937c2bc47fbc49d690"

inherit allarch deploy

do_compile () {
  echo "Hello world!" > deployme.txt
}

do_deploy () {
  install -d ${DEPLOYDIR}
  install -m 644 ${B}/deployme.txt ${DEPLOYDIR}/
}

addtask deploy before do_build after do_compile

(cut here)


Very interesting & verified with the latest master.

Have you filed a bug?  https://bugzilla.yoctoproject.org/


Well, I'm not convinced this is a bug as such. You've created an
"allarch" deploy task, how would you expect this to behave?

"allarch" means that the output from this task is universal and can be
used on all targets. It will therefore get run once.

A "deploy" task is machine specific.

What ends up happening is therefore the task has a stamp is
"universally" created. When you change machine, the checksum of the task
changes, the previous version is removed, the new version is installed.

So in many ways the system is doing exactly what I would expect it to do
and it isn't a bug in that sense.


It's not a bug in the sense that it doesn't do as it was programmed to do. I 
understand what's happening here.


I just think that the logic here is wrong. If "deploy" is machine specific, 
then the implicit "undeploy" should be machine specific too, right?



The real question is how should an "allarch" + "deploy" task behave when
you've specified machine specific paths? Perhaps erroring would be
better?


That would mean that roughly all deploy tasks will fail. At best they're tied 
to MACHINE_ARCH, but never to MACHINE itself.


Would be strange to put PACKAGE_ARCH="${MACHINE}" in a recipe that clearly has 
no dependency on machine specific things. And I wrote "${MACHINE}" here on 
purpose.


I was thinking along the lines of "DEPLOY_DIR_IMAGE must have the same prefix" 
or so.


If I knew the solution, I'd have posted a patch instead of a question or report.

M.


Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
Telefax:  (+31) (0) 499 33 69 70
E-mail: mike.looijm...@topic.nl
Website: www.topic.nl

Please consider the environment before printing this e-mail

Topic zoekt gedreven (embedded) software specialisten!
http://topic.nl/vacatures/topic-zoekt-software-engineers/

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

[OE-core] [PATCH] qemu: Add missing wacom HID descriptor

[Richard Purdie]

The wacom driver we use is missing a HID descriptor causing it not to work
with 3.17 kernels and later. This patch adds in a descriptor to make the
driver work again.

Signed-off-by: Richard Purdie 

diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index c8b400a..3f68a56 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -16,6 +16,7 @@ SRC_URI = "\
 file://larger_default_ram_size.patch \
 file://disable-grabs.patch \
 file://exclude-some-arm-EABI-obsolete-syscalls.patch \
+file://wacom.patch \
 "
 
 SRC_URI_append_class-native = "\
diff --git a/meta/recipes-devtools/qemu/qemu/wacom.patch 
b/meta/recipes-devtools/qemu/qemu/wacom.patch
new file mode 100644
index 000..cd06aa4
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/wacom.patch
@@ -0,0 +1,130 @@
+The USB wacom device is missing a HID descriptor which causes it
+to fail to operate with recent kernels (e.g. 3.17).
+
+This patch adds a HID desriptor to the device, based upon one from 
+real wcom device.
+
+Signed-off-by: Richard Purdie 
+
+Upstream-Status: Submitted
+2014/11/27
+
+Index: qemu-2.1.0/hw/usb/dev-wacom.c
+===
+--- qemu-2.1.0.orig/hw/usb/dev-wacom.c 2014-08-01 15:12:17.0 +0100
 qemu-2.1.0/hw/usb/dev-wacom.c  2014-10-12 12:13:30.540306042 +0100
+@@ -68,6 +68,89 @@
+ [STR_SERIALNUMBER] = "1",
+ };
+ 
++static const uint8_t qemu_tablet_hid_report_descriptor[] = {
++0x05, 0x01,   /* Usage Page (Generic Desktop) */
++0x09, 0x02,   /* Usage (Mouse) */
++0xa1, 0x01,   /* Collection (Application) */
++0x85, 0x01,   /*   Report ID (1) */ 
++0x09, 0x01,   /*   Usage (Pointer) */
++0xa1, 0x00,   /*   Collection (Physical) */
++0x05, 0x09,   /* Usage Page (Button) */
++0x19, 0x01,   /* Usage Minimum (1) */
++0x29, 0x05,   /* Usage Maximum (5) */
++0x15, 0x00,   /* Logical Minimum (0) */
++0x25, 0x01,   /* Logical Maximum (1) */
++0x95, 0x05,   /* Report Count (5) */
++0x75, 0x01,   /* Report Size (1) */
++0x81, 0x02,   /* Input (Data, Variable, Absolute) */
++0x95, 0x01,   /* Report Count (1) */
++0x75, 0x03,   /* Report Size (3) */
++0x81, 0x01,   /* Input (Constant) */
++0x05, 0x01,   /* Usage Page (Generic Desktop) */
++0x09, 0x30,   /* Usage (X) */
++0x09, 0x31,   /* Usage (Y) */
++0x15, 0x81,   /* Logical Minimum (-127) */
++0x25, 0x7f,   /* Logical Maximum (127) */
++0x75, 0x08,   /* Report Size (8) */
++0x95, 0x02,   /* Report Count (2) */
++0x81, 0x06,   /* Input (Data, Variable, Relative) */
++0xc0, /*   End Collection */
++0xc0, /* End Collection */
++0x05, 0x0d,   /* Usage Page (Digitizer) */
++0x09, 0x01,   /* Usage (Digitizer) */
++0xa1, 0x01,   /* Collection (Application) */
++0x85, 0x02,   /*   Report ID (2) */ 
++0xa1, 0x00,   /*   Collection (Physical) */
++0x06, 0x00, 0xff,   /*   Usage Page (Vendor 0xff00) */
++0x09, 0x01,   /*   Usage (Digitizer) */
++0x15, 0x00,   /* Logical Minimum (0) */
++0x26, 0xff, 0x00, /* Logical Maximum (255) */
++0x75, 0x08,   /* Report Size (8) */
++0x95, 0x08,   /* Report Count (8) */
++0x81, 0x02,   /* Input (Data, Variable, Absolute) */
++0xc0, /*   End Collection */
++0x09, 0x01,   /*   Usage (Digitizer) */
++0x85, 0x02,   /*   Report ID (2) */ 
++0x95, 0x01,   /*   Report Count (1) */
++0xb1, 0x02,   /*   FEATURE (2) */
++0xc0, /* End Collection */
++0x06, 0x00, 0xff, /* Usage Page (Vendor 0xff00) */
++0x09, 0x01,   /* Usage (Digitizer) */
++0xa1, 0x01,   /* Collection (Application) */
++0x85, 0x02,   /*   Report ID (2) */ 
++0x05, 0x0d,   /*   Usage Page (Digitizer)  */
++0x09, 0x22,   /*   Usage (Finger) */
++0xa1, 0x00,   /*   Collection (Physical) */
++0x06, 0x00, 0xff, /*   Usage Page (Vendor 0xff00) */
++0x09, 0x01,   /* Usage (Digitizer) */
++0x15, 0x00,   /* Logical Minimum (0) */
++0x26, 0xff, 0x00, /* Logical Maximum */
++0x75, 0x08,   /* Report Size (8) */
++0x95, 0x02,   /* Report Count (2) */
++0x81, 0x02,   /* Input (Data, Variable, Absolute) */
++0x05, 0x01,   

Re: [OE-core] [PATCH] libxml2: fix CVE-2014-3660

[Ahsan, Noor]

Hi,

Sorry for the false alarm. It was included in master but not in dizzy branch. 
Kindly include in that branch as well. Thanks.

Noor

-Original Message-
From: Ahsan, Noor 
Sent: Thursday, November 27, 2014 6:45 PM
To: 'Joe MacDonald'; openembedded-core@lists.openembedded.org
Subject: RE: [OE-core] [PATCH] libxml2: fix CVE-2014-3660

Hello,

We sent out this patch but we haven't received any feedback not it was 
included. Kindly include this in dizzy branch.

Thanks.

Noor

-Original Message-
From: openembedded-core-boun...@lists.openembedded.org 
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Joe 
MacDonald
Sent: Monday, October 20, 2014 10:51 PM
To: openembedded-core@lists.openembedded.org
Subject: [OE-core] [PATCH] libxml2: fix CVE-2014-3660

It was discovered that the patch for CVE-2014-0191 for libxml2 is incomplete.  
It is still possible to have libxml2 incorrectly perform entity substituton 
even when the application using libxml2 explicitly disables the feature.  This 
can allow a remote denial-of-service attack on systems with libxml2 prior to 
2.9.2.

References:
http://www.openwall.com/lists/oss-security/2014/10/17/7

https://www.ncsc.nl/actueel/nieuwsberichten/kwetsbaarheid-ontdekt-in-libxml2.html

Signed-off-by: Joe MacDonald 
---
 meta/recipes-core/libxml/libxml2.inc   |   1 +
 .../libxml/libxml2/libxml2-CVE-2014-3660.patch | 147 +
 2 files changed, 148 insertions(+)
 create mode 100644 meta/recipes-core/libxml/libxml2/libxml2-CVE-2014-3660.patch

diff --git a/meta/recipes-core/libxml/libxml2.inc 
b/meta/recipes-core/libxml/libxml2.inc
index bcf9a62..c729c19 100644
--- a/meta/recipes-core/libxml/libxml2.inc
+++ b/meta/recipes-core/libxml/libxml2.inc
@@ -21,6 +21,7 @@ SRC_URI = 
"ftp://xmlsoft.org/libxml2/libxml2-${PV}.tar.gz;name=libtar \
file://libxml2-CVE-2014-0191-fix.patch \
file://python-sitepackages-dir.patch \
file://libxml-m4-use-pkgconfig.patch \
+   file://libxml2-CVE-2014-3660.patch \
   "
 
 BINCONFIG = "${bindir}/xml2-config"
diff --git a/meta/recipes-core/libxml/libxml2/libxml2-CVE-2014-3660.patch 
b/meta/recipes-core/libxml/libxml2/libxml2-CVE-2014-3660.patch
new file mode 100644
index 000..b9621c9
--- /dev/null
+++ b/meta/recipes-core/libxml/libxml2/libxml2-CVE-2014-3660.patch
@@ -0,0 +1,147 @@
+From be2a7edaf289c5da74a4f9ed3a0b6c733e775230 Mon Sep 17 00:00:00 2001
+From: Daniel Veillard 
+Date: Thu, 16 Oct 2014 13:59:47 +0800
+Subject: Fix for CVE-2014-3660
+
+Issues related to the billion laugh entity expansion which happened to 
+escape the initial set of fixes
+
+Upstream-status: Backport
+Reference: 
+https://git.gnome.org/browse/libxml2/commit/?id=be2a7edaf289c5da74a4f9e
+d3a0b6c733e775230&context=3&ignorews=0&ss=0
+
+Signed-off-by: Joe MacDonald 
+
+diff --git a/parser.c b/parser.c
+index f51e8d2..1d93967 100644
+--- a/parser.c
 b/parser.c
+@@ -130,6 +130,29 @@ xmlParserEntityCheck(xmlParserCtxtPtr ctxt, size_t size,
+ return (0);
+ if (ctxt->lastError.code == XML_ERR_ENTITY_LOOP)
+ return (1);
++
++/*
++ * This may look absurd but is needed to detect
++ * entities problems
++ */
++if ((ent != NULL) && (ent->etype != XML_INTERNAL_PREDEFINED_ENTITY) &&
++  (ent->content != NULL) && (ent->checked == 0)) {
++  unsigned long oldnbent = ctxt->nbentities;
++  xmlChar *rep;
++
++  ent->checked = 1;
++
++  rep = xmlStringDecodeEntities(ctxt, ent->content,
++XML_SUBSTITUTE_REF, 0, 0, 0);
++
++  ent->checked = (ctxt->nbentities - oldnbent + 1) * 2;
++  if (rep != NULL) {
++  if (xmlStrchr(rep, '<'))
++  ent->checked |= 1;
++  xmlFree(rep);
++  rep = NULL;
++  }
++}
+ if (replacement != 0) {
+   if (replacement < XML_MAX_TEXT_LENGTH)
+   return(0);
+@@ -189,9 +212,12 @@ xmlParserEntityCheck(xmlParserCtxtPtr ctxt, size_t size,
+ return (0);
+ } else {
+ /*
+- * strange we got no data for checking just return
++ * strange we got no data for checking
+  */
+-return (0);
++  if (((ctxt->lastError.code != XML_ERR_UNDECLARED_ENTITY) &&
++   (ctxt->lastError.code != XML_WAR_UNDECLARED_ENTITY)) ||
++  (ctxt->nbentities <= 1))
++  return (0);
+ }
+ xmlFatalErr(ctxt, XML_ERR_ENTITY_LOOP, NULL);
+ return (1);
+@@ -2589,6 +2615,7 @@ xmlParserHandlePEReference(xmlParserCtxtPtr ctxt) {
+ name, NULL);
+   ctxt->valid = 0;
+   }
++  xmlParserEntityCheck(ctxt, 0, NULL, 0);
+   } else if (ctxt->input->free != deallocblankswrapper) {
+   input = xmlNewBlanksWrapperInputStream(ctxt, entity);
+   if (xmlPushInput(ctxt, input) < 0) @@ -2759,6 +2786,7 @@ 
+xmlStringLenDecodeEntities(xmlPar

Re: [OE-core] [PATCH] libxml2: fix CVE-2014-3660

[Ahsan, Noor]

Hello,

We sent out this patch but we haven't received any feedback not it was 
included. Kindly include this in dizzy branch.

Thanks.

Noor

-Original Message-
From: openembedded-core-boun...@lists.openembedded.org 
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Joe 
MacDonald
Sent: Monday, October 20, 2014 10:51 PM
To: openembedded-core@lists.openembedded.org
Subject: [OE-core] [PATCH] libxml2: fix CVE-2014-3660

It was discovered that the patch for CVE-2014-0191 for libxml2 is incomplete.  
It is still possible to have libxml2 incorrectly perform entity substituton 
even when the application using libxml2 explicitly disables the feature.  This 
can allow a remote denial-of-service attack on systems with libxml2 prior to 
2.9.2.

References:
http://www.openwall.com/lists/oss-security/2014/10/17/7

https://www.ncsc.nl/actueel/nieuwsberichten/kwetsbaarheid-ontdekt-in-libxml2.html

Signed-off-by: Joe MacDonald 
---
 meta/recipes-core/libxml/libxml2.inc   |   1 +
 .../libxml/libxml2/libxml2-CVE-2014-3660.patch | 147 +
 2 files changed, 148 insertions(+)
 create mode 100644 meta/recipes-core/libxml/libxml2/libxml2-CVE-2014-3660.patch

diff --git a/meta/recipes-core/libxml/libxml2.inc 
b/meta/recipes-core/libxml/libxml2.inc
index bcf9a62..c729c19 100644
--- a/meta/recipes-core/libxml/libxml2.inc
+++ b/meta/recipes-core/libxml/libxml2.inc
@@ -21,6 +21,7 @@ SRC_URI = 
"ftp://xmlsoft.org/libxml2/libxml2-${PV}.tar.gz;name=libtar \
file://libxml2-CVE-2014-0191-fix.patch \
file://python-sitepackages-dir.patch \
file://libxml-m4-use-pkgconfig.patch \
+   file://libxml2-CVE-2014-3660.patch \
   "
 
 BINCONFIG = "${bindir}/xml2-config"
diff --git a/meta/recipes-core/libxml/libxml2/libxml2-CVE-2014-3660.patch 
b/meta/recipes-core/libxml/libxml2/libxml2-CVE-2014-3660.patch
new file mode 100644
index 000..b9621c9
--- /dev/null
+++ b/meta/recipes-core/libxml/libxml2/libxml2-CVE-2014-3660.patch
@@ -0,0 +1,147 @@
+From be2a7edaf289c5da74a4f9ed3a0b6c733e775230 Mon Sep 17 00:00:00 2001
+From: Daniel Veillard 
+Date: Thu, 16 Oct 2014 13:59:47 +0800
+Subject: Fix for CVE-2014-3660
+
+Issues related to the billion laugh entity expansion which happened to 
+escape the initial set of fixes
+
+Upstream-status: Backport
+Reference: 
+https://git.gnome.org/browse/libxml2/commit/?id=be2a7edaf289c5da74a4f9e
+d3a0b6c733e775230&context=3&ignorews=0&ss=0
+
+Signed-off-by: Joe MacDonald 
+
+diff --git a/parser.c b/parser.c
+index f51e8d2..1d93967 100644
+--- a/parser.c
 b/parser.c
+@@ -130,6 +130,29 @@ xmlParserEntityCheck(xmlParserCtxtPtr ctxt, size_t size,
+ return (0);
+ if (ctxt->lastError.code == XML_ERR_ENTITY_LOOP)
+ return (1);
++
++/*
++ * This may look absurd but is needed to detect
++ * entities problems
++ */
++if ((ent != NULL) && (ent->etype != XML_INTERNAL_PREDEFINED_ENTITY) &&
++  (ent->content != NULL) && (ent->checked == 0)) {
++  unsigned long oldnbent = ctxt->nbentities;
++  xmlChar *rep;
++
++  ent->checked = 1;
++
++  rep = xmlStringDecodeEntities(ctxt, ent->content,
++XML_SUBSTITUTE_REF, 0, 0, 0);
++
++  ent->checked = (ctxt->nbentities - oldnbent + 1) * 2;
++  if (rep != NULL) {
++  if (xmlStrchr(rep, '<'))
++  ent->checked |= 1;
++  xmlFree(rep);
++  rep = NULL;
++  }
++}
+ if (replacement != 0) {
+   if (replacement < XML_MAX_TEXT_LENGTH)
+   return(0);
+@@ -189,9 +212,12 @@ xmlParserEntityCheck(xmlParserCtxtPtr ctxt, size_t size,
+ return (0);
+ } else {
+ /*
+- * strange we got no data for checking just return
++ * strange we got no data for checking
+  */
+-return (0);
++  if (((ctxt->lastError.code != XML_ERR_UNDECLARED_ENTITY) &&
++   (ctxt->lastError.code != XML_WAR_UNDECLARED_ENTITY)) ||
++  (ctxt->nbentities <= 1))
++  return (0);
+ }
+ xmlFatalErr(ctxt, XML_ERR_ENTITY_LOOP, NULL);
+ return (1);
+@@ -2589,6 +2615,7 @@ xmlParserHandlePEReference(xmlParserCtxtPtr ctxt) {
+ name, NULL);
+   ctxt->valid = 0;
+   }
++  xmlParserEntityCheck(ctxt, 0, NULL, 0);
+   } else if (ctxt->input->free != deallocblankswrapper) {
+   input = xmlNewBlanksWrapperInputStream(ctxt, entity);
+   if (xmlPushInput(ctxt, input) < 0) @@ -2759,6 +2786,7 @@ 
+xmlStringLenDecodeEntities(xmlParserCtxtPtr ctxt, const xmlChar *str, int len,
+   if ((ctxt->lastError.code == XML_ERR_ENTITY_LOOP) ||
+   (ctxt->lastError.code == XML_ERR_INTERNAL_ERROR))
+   goto int_error;
++  xmlParserEntityCheck(ctxt, 0, ent, 0);
+   if (ent != NULL)
+   ctxt->nbentities += ent->checked / 2;
+   

Re: [OE-core] Deployment for machine X will remove its results from machine Y's deploy dir

[Richard Purdie]

On Thu, 2014-11-27 at 05:02 -0700, Gary Thomas wrote:
> On 2014-11-27 01:35, Mike Looijmans wrote:
> > Here's an example recipe to demonstrate the issue. Save it as "deployme.bb" 
> > into a recipe dir. Then build it for two machines. Building it for one 
> > machine will remove it from the
> > deployment directory of the other. This problem has been bugging me for 
> > months, I had files just "disappear" mysteriously from the deploy directory 
> > and seemingly random times, and
> > now I finally figured out what causes it.
> >
> > (cut here)
> >
> > SUMMARY = "Demonstrate a bug in OE deployment"
> > DESCRIPTION = "Build this package for a machine X, then look at the image's 
> > \
> >   deploy directory. You'll see a deployme.txt there. Now build it for 
> > another \
> >   machine, e.g. "Y". The deployme.txt for machine X will have disappeared \
> >   from the image dir. This appears to be a bug in OE's deployment."
> > LICENSE = "GPLv2"
> > LIC_FILES_CHKSUM = 
> > "file://${COREBASE}/LICENSE;md5=4d92cd373abda3937c2bc47fbc49d690"
> >
> > inherit allarch deploy
> >
> > do_compile () {
> >  echo "Hello world!" > deployme.txt
> > }
> >
> > do_deploy () {
> >  install -d ${DEPLOYDIR}
> >  install -m 644 ${B}/deployme.txt ${DEPLOYDIR}/
> > }
> >
> > addtask deploy before do_build after do_compile
> >
> > (cut here)
> 
> Very interesting & verified with the latest master.
> 
> Have you filed a bug?  https://bugzilla.yoctoproject.org/

Well, I'm not convinced this is a bug as such. You've created an
"allarch" deploy task, how would you expect this to behave?

"allarch" means that the output from this task is universal and can be
used on all targets. It will therefore get run once.

A "deploy" task is machine specific.

What ends up happening is therefore the task has a stamp is
"universally" created. When you change machine, the checksum of the task
changes, the previous version is removed, the new version is installed.

So in many ways the system is doing exactly what I would expect it to do
and it isn't a bug in that sense.

The real question is how should an "allarch" + "deploy" task behave when
you've specified machine specific paths? Perhaps erroring would be
better?

Cheers,

Richard


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

[OE-core] [PATCH] When building with systemd based image, udev-hwdb postinstall script will fail because of not passing correct CPU option. So fix it by passing correct QEMU_OPTIONS.

[Gaurang Shastri]

Signed-off-by: Gaurang Shastri 
---
 meta/classes/qemu.bbclass |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/classes/qemu.bbclass b/meta/classes/qemu.bbclass
index b2cf85d..c373855 100644
--- a/meta/classes/qemu.bbclass
+++ b/meta/classes/qemu.bbclass
@@ -30,8 +30,9 @@ def qemu_run_binary(data, rootfs_path, binary):
 libdir = rootfs_path + data.getVar("libdir", False)
 base_libdir = rootfs_path + data.getVar("base_libdir", False)
 oldest_kernel = data.getVar("OLDEST_KERNEL", True)
+qemu_option = data.getVar("QEMU_OPTIONS",True)
 
-return "PSEUDO_UNLOAD=1 " + qemu_binary + " -r " + oldest_kernel + " -L " 
+ rootfs_path\
+return "PSEUDO_UNLOAD=1 " + qemu_binary + " " + qemu_option + " -r " + 
oldest_kernel + " -L " + rootfs_path\
 + " -E LD_LIBRARY_PATH=" + libdir + ":" + base_libdir + " "\
 + rootfs_path + binary
 
-- 
1.7.9.5

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

Re: [OE-core] Deployment for machine X will remove its results from machine Y's deploy dir

[Gary Thomas]

On 2014-11-27 01:35, Mike Looijmans wrote:

Here's an example recipe to demonstrate the issue. Save it as "deployme.bb" 
into a recipe dir. Then build it for two machines. Building it for one machine will 
remove it from the
deployment directory of the other. This problem has been bugging me for months, I had 
files just "disappear" mysteriously from the deploy directory and seemingly 
random times, and
now I finally figured out what causes it.

(cut here)

SUMMARY = "Demonstrate a bug in OE deployment"
DESCRIPTION = "Build this package for a machine X, then look at the image's \
  deploy directory. You'll see a deployme.txt there. Now build it for another \
  machine, e.g. "Y". The deployme.txt for machine X will have disappeared \
  from the image dir. This appears to be a bug in OE's deployment."
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = 
"file://${COREBASE}/LICENSE;md5=4d92cd373abda3937c2bc47fbc49d690"

inherit allarch deploy

do_compile () {
 echo "Hello world!" > deployme.txt
}

do_deploy () {
 install -d ${DEPLOYDIR}
 install -m 644 ${B}/deployme.txt ${DEPLOYDIR}/
}

addtask deploy before do_build after do_compile

(cut here)


Very interesting & verified with the latest master.

Have you filed a bug?  https://bugzilla.yoctoproject.org/

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

[OE-core] [PATCH] When building with systemd based image, udev-hwdb postinstall script will fail because of not passing correct CPU option. So fix it by passing correct QEMU_OPTIONS.

[Gaurang Shastri]

Signed-off-by: Gaurang Shastri 
---
 meta/classes/qemu.bbclass |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/classes/qemu.bbclass b/meta/classes/qemu.bbclass
index b2cf85d..c373855 100644
--- a/meta/classes/qemu.bbclass
+++ b/meta/classes/qemu.bbclass
@@ -30,8 +30,9 @@ def qemu_run_binary(data, rootfs_path, binary):
 libdir = rootfs_path + data.getVar("libdir", False)
 base_libdir = rootfs_path + data.getVar("base_libdir", False)
 oldest_kernel = data.getVar("OLDEST_KERNEL", True)
+qemu_option = data.getVar("QEMU_OPTIONS",True)
 
-return "PSEUDO_UNLOAD=1 " + qemu_binary + " -r " + oldest_kernel + " -L " 
+ rootfs_path\
+return "PSEUDO_UNLOAD=1 " + qemu_binary + " " + qemu_option + " -r " + 
oldest_kernel + " -L " + rootfs_path\
 + " -E LD_LIBRARY_PATH=" + libdir + ":" + base_libdir + " "\
 + rootfs_path + binary
 
-- 
1.7.9.5

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

[OE-core] Deployment for machine X will remove its results from machine Y's deploy dir

[Mike Looijmans]

Here's an example recipe to demonstrate the issue. Save it as "deployme.bb" 
into a recipe dir. Then build it for two machines. Building it for one machine 
will remove it from the deployment directory of the other. This problem has 
been bugging me for months, I had files just "disappear" mysteriously from the 
deploy directory and seemingly random times, and now I finally figured out 
what causes it.


(cut here)

SUMMARY = "Demonstrate a bug in OE deployment"
DESCRIPTION = "Build this package for a machine X, then look at the image's \
 deploy directory. You'll see a deployme.txt there. Now build it for another \
 machine, e.g. "Y". The deployme.txt for machine X will have disappeared \
 from the image dir. This appears to be a bug in OE's deployment."
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = 
"file://${COREBASE}/LICENSE;md5=4d92cd373abda3937c2bc47fbc49d690"


inherit allarch deploy

do_compile () {
echo "Hello world!" > deployme.txt
}

do_deploy () {
install -d ${DEPLOYDIR}
install -m 644 ${B}/deployme.txt ${DEPLOYDIR}/
}

addtask deploy before do_build after do_compile

(cut here)


Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
Telefax:  (+31) (0) 499 33 69 70
E-mail: mike.looijm...@topic.nl
Website: www.topic.nl

Please consider the environment before printing this e-mail

Topic zoekt gedreven (embedded) software specialisten!
http://topic.nl/vacatures/topic-zoekt-software-engineers/

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

Re: [OE-core] Why does building an image for machine X delete the bootloader (and kernel) for machine Y?

[Mike Looijmans]

On 11/27/2014 08:46 AM, Mike Looijmans wrote:

On 11/26/2014 07:44 PM, Mike Looijmans wrote:

On 11/26/2014 03:57 PM, Paul Eggleton wrote:

On Wednesday 26 November 2014 14:20:46 Mike Looijmans wrote:

On 11/26/2014 12:31 PM, Paul Eggleton wrote:

Hi Mike,

On Wednesday 26 November 2014 09:19:13 Mike Looijmans wrote:

I do a:

MACHINE=X bitbake my-image

This DEPENDS on a virtual bootloader, which will produce a BOOT.BIN file
in
the deploy directory, which is tmp-glibc/deploy.images/X/

If I then do a:

MACHINE=Y bitbake my-image

the BOOT.BIN in tmp-glibc/deploy.images/X/ is suddenly gone!

If i do a

MACHINE=X bitbake my-image

then the the BOOT.BIN in tmp-glibc/deploy.images/Y/ is suddenly gone, and
the one for the X machine appears again. The bootloader recipe is not
being
rebuilt at all.

The machines have the same MACHINE_ARCH, they differ on only minor points
(the FPGA).

What is going on here?


I can't be sure, but my guess is the recipe is not marked as being
machine-
specific (i.e. PACKAGE_ARCH is not set to "${MACHINE_ARCH}" - is that the
case?) but there is still some variable dependency on a variable that has
a machine-specific value. If it's not obvious from the recipe, check if
there are two sets of tasks for the bootloader recipe in the sstate
cache, and then use bitbake-diffsigs to compare the sigdata/siginfo
files.


MACHINE is actually "topic-miami-florida-med-xc7z015" or
"topic-miami-florida-med-xc7z030"

Both machines have MACHINE_ARCH = "topic_miami_florida_med" since they only
differ in the FPGA subsystem, but share all the rest (kernel, bootloader,
etc).

Is it forbidden to share $MACHINE_ARCH between $MACHINEs? (And if so, why
does MACHINE_ARCH even exist?)


I don't know for sure, but I don't think that is forbidden. I'm not sure
that's the issue here though.


The BSP layer for the topic-miami machines is here (yes, you can build OE or
Yocto images with it, but I have yet some more work to do to make it a
proper BSP...):
https://github.com/topic-embedded-products/meta-topic


Is it u-boot that's the actual bootloader we are talking about here?


Yep.

u-boot-spl to be exact. The BOOT.bin is just one of the files that disappears,
it's the firststage loader built by u-boot.


It happens anytime I switch between machines. Building for one will delete the
files for the other. It will delete all bootloader and kernel files.

Running
MACHINE=topic-miami-florida-med-xc7z030 bitbake virtual/kernel -c deploy
deletes the kernel for the xc7z015, and places it in the xz7z030 deploy dir, and
MACHINE=topic-miami-florida-med-xc7z015 bitbake virtual/kernel -c deploy
does the opposite.

Probably some unforeseen effect of deploy when machines share the same arch?



It's not limited to kernel and bootloader either, it happens for ANY task that 
has a "deploy". The deploy task will remove files for another MACHINE, and 
then replace them with its own. It does not take the MACHINE into 
consideration, even though the deployment directory is specific to a machine 
(and not just MACHINE_ARCH).


Something similar happens if you create a package that is generic for all 
machines (PACKAGE_ARCH="all" or so), but needs to be deployed. Building for 
another machine will remove that package from the previous machine's 
deployment directory.


Seems to be a bug in OE. I'll create an example recipe to demonstrate it for 
any target.





Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
Telefax:  (+31) (0) 499 33 69 70
E-mail: mike.looijm...@topic.nl
Website: www.topic.nl

Please consider the environment before printing this e-mail

Topic zoekt gedreven (embedded) software specialisten!
http://topic.nl/vacatures/topic-zoekt-software-engineers/

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