Re: [OE-core] STAGING_KERNEL_DIR not populated with kernel source
On Aug 26, 2015, at 4:33 AM, Nageswari Srinivasan nageswar...@verifone.com wrote: Hi, While migrating my current build to fido, STAGING_KERNEL_DIR is not getting populated with kernel sources so custom module builds are failing? Any pointers here? you should be able to use STAGING_KERNEL_BUILDDIR regards, Nageswari This electronic message, including attachments, is intended only for the use of the individual or company named above or to which it is addressed. The information contained in this message shall be considered confidential and proprietary, and may include confidential work product. If you are not the intended recipient, please be aware that any unauthorized use, dissemination, distribution or copying of this message is strictly prohibited. If you have received this email in error, please notify the sender by replying to this message and deleting this email immediately. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org mailto:Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core http://lists.openembedded.org/mailman/listinfo/openembedded-core signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2 1/1] classes/whitelist: add class to allow whitelisting recipes from a layer
On Aug 27, 2015, at 5:36 AM, Paul Eggleton paul.eggle...@linux.intel.com
wrote:
Allow restricting recipes brought from a layer to a specified list. This
is similar in operation to blacklist.bbclass, but instead specifies a
per-layer whitelist of recipes (matched by PN or BPN) that are able to
be built from the layer - anything else is skipped. This is potentially
useful where you want to bring in a select set of recipes from a larger
layer e.g. meta-oe.
For the record, I am not in favor of such feature in OE, Distros can still use
BBMASK if they wish to
Implements [YOCTO #8150].
Signed-off-by: Paul Eggleton paul.eggle...@linux.intel.com
---
meta/classes/whitelist.bbclass | 34 ++
1 file changed, 34 insertions(+)
create mode 100644 meta/classes/whitelist.bbclass
diff --git a/meta/classes/whitelist.bbclass b/meta/classes/whitelist.bbclass
new file mode 100644
index 000..ab6ac73
--- /dev/null
+++ b/meta/classes/whitelist.bbclass
@@ -0,0 +1,34 @@
+# Class that allows you to restrict the recipes brought from a layer to
+# a specified list. This is similar in operation to blacklist.bbclass
+# but note the difference in how PNWHITELIST is set - we don't use varflags
+# here, the recipe name goes in the value and we use an override for the
+# layer name (although this is not strictly required - you can have one
+# PNWHITELIST value shared by all of the layers specified in
+# PNWHITELIST_LAYERS). The layer name used here is actually the name that
+# gets added to BBFILE_COLLECTIONS in the layer's layer.conf, which may
+# differ from how the layer is otherwise known - e.g. meta-oe uses
+# openembedded-layer.
+#
+# INHERIT += whitelist
+# PNWHITELIST_LAYERS = layername
+# PNWHITELIST_layername = recipe1 recipe2
+#
+# If you would prefer to set a reason message other than the default, you
+# can do so:
+#
+# PNWHITELIST_REASON_layername = not supported by ${DISTRO}
+
+python() {
+layer = bb.utils.get_file_layer(d.getVar('FILE', True), d)
+if layer:
+layers = (d.getVar('PNWHITELIST_LAYERS', True) or '').split()
+if layer in layers:
+localdata = bb.data.createCopy(d)
+localdata.setVar('OVERRIDES', layer)
+whitelist = (localdata.getVar('PNWHITELIST', True) or '').split()
+if not (d.getVar('PN', True) in whitelist or d.getVar('BPN',
True) in whitelist):
+reason = localdata.getVar('PNWHITELIST_REASON', True)
+if not reason:
+reason = 'not in PNWHITELIST for layer %s' % layer
+raise bb.parse.SkipRecipe(reason)
+}
--
2.1.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
signature.asc
Description: Message signed with OpenPGP using GPGMail
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 4/5] iw: support and enable separate build dir
On 27 August 2015 at 21:48, Christopher Larson kerg...@gmail.com wrote:
From: Christopher Larson chris_lar...@mentor.com
Signed-off-by: Christopher Larson chris_lar...@mentor.com
---
.../iw/iw/separate-objdir.patch| 55
++
meta/recipes-connectivity/iw/iw_4.1.bb | 4 ++
2 files changed, 59 insertions(+)
create mode 100644 meta/recipes-connectivity/iw/iw/separate-objdir.patch
diff --git a/meta/recipes-connectivity/iw/iw/separate-objdir.patch
b/meta/recipes-connectivity/iw/iw/separate-objdir.patch
new file mode 100644
index 000..e29e461
--- /dev/null
+++ b/meta/recipes-connectivity/iw/iw/separate-objdir.patch
@@ -0,0 +1,55 @@
+From 9e27fc2e1b3dc8c36ef6a502edffc3a3d84d9dd9 Mon Sep 17 00:00:00 2001
+From: Christopher Larson chris_lar...@mentor.com
+Date: Wed, 26 Aug 2015 17:23:48 -0700
+Subject: [PATCH] Support separation of SRCDIR and OBJDIR
+
+Typical use of VPATH to locate the sources.
+
+Signed-off-by: Christopher Larson chris_lar...@mentor.com
+
Upstream-Status ?
- Jussi
+---
+ Makefile | 7 +--
+ version.sh | 2 +-
+ 2 files changed, 6 insertions(+), 3 deletions(-)
+
+diff --git a/Makefile b/Makefile
+index 548591a..da8d33a 100644
+--- a/Makefile
b/Makefile
+@@ -1,5 +1,8 @@
+ MAKEFLAGS += --no-print-directory
+
++SRCDIR ?= $(dir $(lastword $(MAKEFILE_LIST)))
++OBJDIR ?= $(PWD)
++VPATH = $(SRCDIR)
+ PREFIX ?= /usr
+ SBINDIR ?= $(PREFIX)/sbin
+ MANDIR ?= $(PREFIX)/share/man
+@@ -95,11 +98,11 @@ VERSION_OBJS := $(filter-out version.o, $(OBJS))
+ version.c: version.sh $(patsubst %.o,%.c,$(VERSION_OBJS)) nl80211.h iw.h
Makefile \
+ $(wildcard .git/index .git/refs/tags)
+ @$(NQ) ' GEN ' $@
+- $(Q)./version.sh $@
++ $(Q)cd $(SRCDIR) ./version.sh $(OBJDIR)/$@
+
+ %.o: %.c iw.h nl80211.h
+ @$(NQ) ' CC ' $@
+- $(Q)$(CC) $(CFLAGS) -c -o $@ $
++ $(Q)$(CC) -I$(SRCDIR) $(CFLAGS) -c -o $@ $
+
+ ifeq ($(IW_ANDROID_BUILD),)
+ iw: $(OBJS)
+diff --git a/version.sh b/version.sh
+index 5354383..fa954cf 100755
+--- a/version.sh
b/version.sh
+@@ -5,5 +5,5 @@ OUT=$1
+
+ v=$VERSION
+
+-echo '#include iw.h' $OUT
++echo '#include iw.h' $OUT
+ echo const char iw_version[] = \$v\; $OUT
+--
+2.2.1
+
diff --git a/meta/recipes-connectivity/iw/iw_4.1.bb
b/meta/recipes-connectivity/iw/iw_4.1.bb
index 8e27862..fafb0e3 100644
--- a/meta/recipes-connectivity/iw/iw_4.1.bb
+++ b/meta/recipes-connectivity/iw/iw_4.1.bb
@@ -11,6 +11,7 @@ DEPENDS = libnl
SRC_URI = http://www.kernel.org/pub/software/network/iw/${BP}.tar.gz \
file://0001-iw-version.sh-don-t-use-git-describe-for-versioning.patch \
+ file://separate-objdir.patch \
SRC_URI[md5sum] = 68c282285c71c956069957e9ca10a6a7
@@ -19,10 +20,13 @@ SRC_URI[sha256sum] =
14bfc627b37f7f607e4ffa63a70ded15fa2ea85177f703cb17d7fe36f9
inherit pkgconfig
EXTRA_OEMAKE = \
+-f '${S}/Makefile' \
+\
'PREFIX=${prefix}' \
'SBINDIR=${sbindir}' \
'MANDIR=${mandir}' \
+B = ${WORKDIR}/build
do_install() {
oe_runmake 'DESTDIR=${D}' install
--
2.2.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/6] gmp: Bring back version 4.2.1 (LGPL 2.1+)
On 28 August 2015 at 09:03, Khem Raj raj.k...@gmail.com wrote: On Aug 27, 2015, at 6:05 AM, Jussi Kukkonen jussi.kukko...@intel.com wrote: gmp 4.2.1 was removed in f181c6ce8b apparently accidentally: It was not noticed that 4.2.1 is LGPL 2.1 (and not GPL) so provides a useful alternative to the newer GPLv2 | LGPLv3 version. * Reintroduce 4.2.1. The source includes files that are GPL but the library package is LGPL 2.1+ * Also reintroduce the two patches removed in f181c6ce8b. * Refactor gmp.inc: gmp 6.0.0 build should not be affected in any way. * Update 6.0.0 license from GPLv2 | LGPLv3 to GPLv2+ | LGPLv3+. [YOCTO #8197] there are issues with gmp on arm especially thumb mode. What kind of testing have you done on this ? I have not tested on arm and at don't really have means to do so. Suggestions to limit the possible harm are welcome. Jussi -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH V3 3/3] runqemu: Define OECORE_MACHINE_SYSROOT on setup_sysroot
On Tue, 2015-07-14 at 20:07 +, leonardo.sandoval.gonza...@linux.intel.com wrote: From: Leonardo Sandoval leonardo.sandoval.gonza...@linux.intel.com At least the OVFM (UEFI Firmware for Qemu and KVM) recipe stores the BIOS under $OE_TMPDIR/sysroots/$MACHINE, now defined as OECORE_MACHINE_SYSROOT. The latter is used when searching BIOS, VGA BIOS and keymaps. As a example, to boot a OVFM BIOS, one can run the following command: $ runqemu qemux86-64 core-image-minimal \ biosdir=usr/share/ovmf \ biosfilename=bios.bin \ nographic Note the bios* parameters: these two are needed to specify the subfolder (parent folder is OECORE_MACHINE_SYSROOT) and BIOS filename (without it, it picks a BIOS named bios-256k.bin). While researching the nvram support question I came across the ovmf whitepaper [1] showing how to use OVMF via -drive if=pflash,format=raw,file=fedora.flash (where fedora.flash is a per-vm copy of OVMF.fd = bios.bin in the sysroot). I kept wondering why you were using -bios bios.bin instead of the -drive method, and how that would affect nvram support. Then I found a pretty clear statement by Laszlo Ersek, one of the OVMF co-maintainers, saying [2] that -bios and the nvram support possible with it (storing in an NvRam file in the EFI boot partition) are a kludge that should not be used anymore. So in other words, this particular patch needs further work. Perhaps add an ovmf keyword (selecting the bios.bin as pflash drive), file name handling (treat anything ending in .bin or .fd as pflash, supporting more than one) and a OVMF env variable with a corresponding colon separated list of pflash files? I also wonder about the bios.bin name and the .bin suffix. I think it would be better to stick with the upstream convention and just install the file in the sysroot as OVMF.fd. This simplifies the file name handling such that only .fd is special. Note that the upstream discussion was about per-vm nvram storage. I think in the context of runqemu it is okay to have a single file per build configuration, because effectively we are creating a single machine with one OS image. What's less nice is that the sysroot will get modified when using bios.bin as pflash drive. Resetting the nvram needs to be done with bitbake -c clean ovmf bitbake ovmf. Both is not obvious. Perhaps if runqemu picks up the file automatically from the sysroot (the ovmf keyword usage), it should make a copy in tmp (on first run) and then use that copy instead? [1] http://www.linux-kvm.org/downloads/lersek/ovmf-whitepaper-c770f8c.txt [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764918#47 -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2 0/4] Sign packages in RPM feeds
Hi,
On 27/08/15 12:31, Markus Lehtonen
openembedded-core-boun...@lists.openembedded.org on behalf of
markus.lehto...@linux.intel.com wrote:
Second iteration of my patchset. I tried to address the issues pointed
out by
Mark:
1. The gpg key is not imported to the (temporary) rpm databases used by
createrepo. Instead, createrepo is patched to ignore signature
verification altogether.
2. There is a new optional config variable GPG_BIN which can be used to
define the gpg binary used for signing.
3. The filename of the public keys (published with the package feed and
depoyed into the target rootfs as part of os-release package) is now
postfixed with -${DISTRO_VERSION}.
[YOCTO #8134]
*** BLURB HERE ***
Markus Lehtonen (4):
createrepo: disable RPM signature validation
package_rpm: support signing of rpm packages
os-release: add the public package-signing key
package_manager: support for signed RPM package feeds
meta/classes/package_rpm.bbclass | 5 ++
meta/classes/sign_rpm.bbclass | 60
++
meta/lib/oe/package_manager.py | 40 +++
meta/recipes-core/os-release/os-release.bb | 11
...dumpMetadata-disable-signature-validation.patch | 31 +++
.../createrepo/createrepo_0.4.11.bb| 17 +++---
6 files changed, 156 insertions(+), 8 deletions(-)
create mode 100644 meta/classes/sign_rpm.bbclass
create mode 100644
meta/recipes-support/createrepo/createrepo/dumpMetadata-disable-signature-
validation.patch
Please use a slightly updated version of the patchset found here:
git://git.openembedded.org/openembedded-core-contrib marquiz/rpmsign
http://git.openembedded.org/openembedded-core-contrib/log/?h=marquiz/rpmsig
n
I noticed some typos in the commit messages of my v2 patchset (GPG_CMD vs.
GPG_BIN). Also, I added a comment header to the sign_rpm.bbclass file.
Thanks,
Markus
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] openssh: Upgrade 7.0p1 - 7.1p1
This is a bugfix release.
Signed-off-by: Jussi Kukkonen jussi.kukko...@intel.com
---
.../openssh/{openssh_7.0p1.bb = openssh_7.1p1.bb}| 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-connectivity/openssh/{openssh_7.0p1.bb =
openssh_7.1p1.bb} (97%)
diff --git a/meta/recipes-connectivity/openssh/openssh_7.0p1.bb
b/meta/recipes-connectivity/openssh/openssh_7.1p1.bb
similarity index 97%
rename from meta/recipes-connectivity/openssh/openssh_7.0p1.bb
rename to meta/recipes-connectivity/openssh/openssh_7.1p1.bb
index 67abe57..eeeb4b4 100644
--- a/meta/recipes-connectivity/openssh/openssh_7.0p1.bb
+++ b/meta/recipes-connectivity/openssh/openssh_7.1p1.bb
@@ -24,8 +24,8 @@ SRC_URI =
ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-${PV}.tar.
PAM_SRC_URI = file://sshd
-SRC_URI[md5sum] = 831883f251ac34f0ab9c812acc24ee69
-SRC_URI[sha256sum] =
fd5932493a19f4c81153d812ee4e042b49bbd3b759ab3d9344abecc2bc1485e5
+SRC_URI[md5sum] = 8709736bc8a8c253bc4eeb4829888ca5
+SRC_URI[sha256sum] =
fc0a6d2d1d063d5c66dffd952493d0cda256cad204f681de0f84ef85b2ad8428
inherit useradd update-rc.d update-alternatives systemd
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH V3 0/3] Add UEFI firmware for qemux86*
On Thu, 2015-08-27 at 14:50 -0500, Leonardo Sandoval wrote:
On 08/27/2015 08:19 AM, Patrick Ohly wrote:
When I use runqemu, it ends up invoking qemu with -vga vmware. With
that, I don't see any output from TianoCore and booting hangs. It boots
when disabling graphical output (serial nographic as parameter of
runqemu) or when explicitly selecting a different graphics
('qemuparams=-vga std'). Might be worthwhile adding to the commit
message.
In the 3/3 commit's description, there is a command line with the
nographic parameter. I did not test with any other kernel command line.
True, that example works. But it is not clear that the nographic is
important. Being explicit about it and adding the graphical case would
be useful.
Do you happen to know how non-volatile EFI variables are handled? There
are several posts from around 2012 saying that qemu does not support
storing nvram persistently (for example, [1]). I've not seen anything
more recent directly contradicting that, but there seems to be
something, at least in Fedora [2]. That patch mentions that OVMF [...]
works in two
modes: 1) Code and UEFI variable store is mixed in one file.
sorry, I do not know.
I think this will require further work - see my comment on the runqemu
patch.
Do you have time for a forth revision?
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2 1/1] classes/whitelist: add class to allow whitelisting recipes from a layer
On Thursday 27 August 2015 23:07:44 Khem Raj wrote: On Aug 27, 2015, at 5:36 AM, Paul Eggleton paul.eggle...@linux.intel.com wrote: Allow restricting recipes brought from a layer to a specified list. This is similar in operation to blacklist.bbclass, but instead specifies a per-layer whitelist of recipes (matched by PN or BPN) that are able to be built from the layer - anything else is skipped. This is potentially useful where you want to bring in a select set of recipes from a larger layer e.g. meta-oe. For the record, I am not in favor of such feature in OE, Distros can still use BBMASK if they wish to This is significantly easier to use than BBMASK though. (Perhaps that's why you don't like it?) I think we need to be realistic here as I said in my most recent reply to the other thread - people will do this using whatever mechanism is available whether we like it or not. And what are they saying by doing so? They're effectively telling us that they can't consume the recipes in the way we are currently collecting them together. We know what the proper fix for the problem is (increased splitting of large layers such as meta-oe), it may not be easy but other than workarounds like this I don't see an alternative. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] bind: remove dependency on bind in bind-dev
On Thursday 27 August 2015 09:19:09 Khem Raj wrote: On Thu, Aug 27, 2015 at 9:01 AM, Ross Burton ross.bur...@intel.com wrote: bind doesn't ship shared libraries only static libraries, so the default dependency on PN from PN-dev is pointless and means that an image with bind-dev installed (via dhcp-dev's automatic dependency) ends up with named installed and started on boot which is rarely intended. I see similar issues in meta-oe I wish this could be abstracted out to a general solution would be awesome detecting if there are no .so in PN detach PN-dev from it. Agreed - I've filed an enhancement: https://bugzilla.yoctoproject.org/show_bug.cgi?id=8222 Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] selftest/manifest.py: Test to verify rootfs manifest
On Thursday 27 August 2015 10:50:51 Benjamin Esquivel wrote:
Hey Paul, thanks for looking at this, check the comments below.
On Thu, 2015-08-27 at 09:34 +0100, Paul Eggleton wrote:
Hi Benjamin / Mariano,
On Wednesday 26 August 2015 12:26:02 Benjamin Esquivel wrote:
Adding a new test to verify if the packages in the
manifest files actually exists in pkgdata.
-adding a setUpClass for when more tests get created here
-check for the paths and fail gracefully if not there
-skip the test when there are no manifest files to check
-debug prints for failure analysis
[YOCTO#8028]
Signed-off-by: Benjamin Esquivel benjamin.esqui...@linux.intel.com
Signed-off-by: Mariano Lopez mariano.lo...@linux.intel.com
---
meta/lib/oeqa/selftest/manifest.py | 52
++ 1 file changed, 52
insertions(+)
create mode 100644 meta/lib/oeqa/selftest/manifest.py
diff --git a/meta/lib/oeqa/selftest/manifest.py
b/meta/lib/oeqa/selftest/manifest.py new file mode 100644
index 000..c2bc945
--- /dev/null
+++ b/meta/lib/oeqa/selftest/manifest.py
@@ -0,0 +1,52 @@
+import unittest
+import os
+from glob import glob
+
+from oeqa.selftest.base import oeSelfTest
+from oeqa.utils.commands import get_bb_var
+from oeqa.utils.decorators import testcase
+
+class VerifyManifest(oeSelfTest):
+'''Tests for the manifest files and contents of an image'''
+
+@classmethod
+def setUpClass(self):
+
+# get directory locations from variable values and check
them
+self.deploy_dir_image = get_bb_var('DEPLOY_DIR_IMAGE');
+if not self.deploy_dir_image \
+or not os.path.isdir(self.deploy_dir_image):
+raise unittest.SkipTest({}: DEPLOY_DIR_IMAGE does not
exist:
{}\ +.format(VerifyManifest,
self.deploy_dir_image))
+
+self.pkgdata_dir = get_bb_var('PKGDATA_DIR');
+if not self.pkgdata_dir \
+or not os.path.isdir(self.pkgdata_dir):
+raise unittest.SkipTest({}: PKGDATA_DIR does not
exist: {}\
+.format(VerifyManifest, self.pkgdata_dir))
+
+# get the manifest files
+# no need to try: since glob would return an empty list if
+# the path is non-existant
+self.manifest_files = glob(%s/*.manifest %
self.deploy_dir_image)
+self.log.debug(manifest files:
{}.format(self.manifest_files)) +
if not self.manifest_files:
+raise unittest.SkipTest({}: No manifest files found
in: {}\
+.format(VerifyManifest, self.deploy_dir_image))
+
+
+def test_manifest_entries(self):
+'''Verifying the manifest entries as packages '''
+testname = self.id().split('.')[-1]
+rundir = os.path.join(self.pkgdata_dir, runtime-reverse)
+
+errmsg = ERROR: Package %s is in manifest but not in
pkgdata
+for manifest in self.manifest_files:
+with open(manifest, r) as mfile:
+for manifest_entries in mfile:
+pkg = manifest_entries.split()[0]
+pkgfile = os.path.join(rundir, pkg)
+self.log.debug({}: looking for {}\
+.format(testname, pkgfile))
+self.assertTrue(os.path.isfile(pkgfile),
+errmsg % pkg)
Shouldn't this test actually be building an image (e.g. using
bitbake('core-image-minimal') ) in order to ensure there's a manifest
file for
it to look at? Then you can make the test fail rather than skipping
if the file
isn't there or doesn't contain a small set of packages we know should
be
listed.
The reason the actual build of an image was not included in the test is
because it is abstracted from it. That's why it contains checks for
when the manifests are not there it skips the test instead of failing.
This would give you the chance to write some level of abstraction that
is able to have test subjects (i.e. subject A: core-image-minimal with
systemd and ipk). Otherwise you're locking the test to a single
scenario which is usually the most common. All the corner cases are
hidden from that scope of testing.
On the other hand, if we had that design I'm talking about we could
easily have a default behavior that does exactly what you're proposing.
What do you think?
We want oe-selftest to be able to objectively test that expected functionality
works when run unattended (as it is on the autobuilder), so if there are
multiple scenarios to test then we probably need to be explicitly setting
those up and testing them here rather than expecting the user to set them up
beforehand. If that adds time to the oe-selftest run, well, so be it.
Also while you're
Re: [OE-core] [PATCH 3/3] package_manager: support for signed RPM package feeds
Hi,
On 27/08/15 15:03, Mark Hatle mark.ha...@windriver.com wrote:
On 8/26/15 11:27 PM, Markus Lehtonen wrote:
Hi Mark,
On 26/08/15 18:10, Mark Hatle mark.ha...@windriver.com wrote:
On 8/26/15 6:18 AM, Markus Lehtonen wrote:
This change makes it possible to create GPG signed RPM package feeds -
i.e. package feed with GPG signed metadata (repodata). All deployed
RPM
repositories will be signed and the GPG public key is copied to the
rpm
deployment directory.
In order to enable the new feature one needs to define four variables
in
bitbake configuration.
1. 'PACKAGE_FEED_SIGN = 1' enabling the feature
2. 'PACKAGE_FEED_GPG_NAME = key_id' defining the GPG key to use
for
signing
3. 'PACKAGE_FEED_GPG_PASSPHRASE_FILE = path_to_file' pointing to a
file containing the passphrase for the secret signing key
4. 'PACKAGE_FEED_GPG_PUBKEY = path_to_pubkey' pointing to the
corresponding public key (in armor format)
[YOCTO #8134]
Signed-off-by: Markus Lehtonen markus.lehto...@linux.intel.com
---
meta/lib/oe/package_manager.py | 24 ++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/meta/lib/oe/package_manager.py
b/meta/lib/oe/package_manager.py
index 753b3eb..5d7ef54 100644
--- a/meta/lib/oe/package_manager.py
+++ b/meta/lib/oe/package_manager.py
@@ -113,8 +113,15 @@ class RpmIndexer(Indexer):
rpm_pubkey = self.d.getVar('RPM_GPG_PUBKEY', True)
else:
rpm_pubkey = None
+if self.d.getVar('PACKAGE_FEED_SIGN', True) == '1':
+pkgfeed_gpg_name = self.d.getVar('PACKAGE_FEED_GPG_NAME',
True)
+pkgfeed_gpg_pass =
self.d.getVar('PACKAGE_FEED_GPG_PASSPHRASE_FILE', True)
+else:
+pkgfeed_gpg_name = None
+pkgfeed_gpg_pass = None
index_cmds = []
+repo_sign_cmds = []
key_import_cmds = []
rpm_dirs_found = False
for arch in archs:
@@ -126,10 +133,16 @@ class RpmIndexer(Indexer):
continue
if rpm_pubkey:
-key_import_cmds.append(%s --define '_dbpath %s'
--import %s %
+key_import_cmds.append(%s --dbpath '%s' --import
%s %
(rpm_bin, dbpath, rpm_pubkey))
index_cmds.append(%s --dbpath %s --update -q %s % \
(rpm_createrepo, dbpath, arch_dir))
+if pkgfeed_gpg_name:
+repomd_file = os.path.join(arch_dir, 'repodata',
'repomd.xml')
+gpg_cmd = gpg2 --detach-sign --armor --batch
--no-tty
--yes \
+ --passphrase-file '%s' -u '%s' %s % \
+ (pkgfeed_gpg_pass, pkgfeed_gpg_name,
repomd_file)
+repo_sign_cmds.append(gpg_cmd)
I've had problems in the past hard coding 'gpg' or 'gpg2' as the name
to
use.
Can we get this to be dynamic.. even if it's a system level define for
what
GPG/PGP program to use?
OK, I can introduce a new variable for defining this.
Also I'd forgotten about it until there. RPM has a similar variable to
define
the GPG program to use. So using that variable (_signature) and
defaulting to
the same item would be a good idea.
I think this is not feasible as we're actually using the host's gpg(2)
here and rpm might not even be available.
Sorry I listed the wrong variable.. What I was referring to was the gpg
program. See below..
What I'm asking for is similar to the above of replacing:
gpg_cmd = gpg2 --detach-sign --armor --batch --no-tty --yes
with something like:
gpg_cmd = d.getVar(GPG, True) + --detach-sign --armor --batch --no-tty
--yes
In the sections where you setup the RPM macros you would define signature
in the
same way:
(patch 1/3)
if gpg_name:
cmd += --define '%%_gpg_name %s' % gpg_name
cmd += --define '__gpg %s' --define '%%_gpg_name %s' % (d.getVar(GPG,
True), gpg_name)
I got the point and did something along these lines in my v2 patchset.
Although the variable name I used was GPG_BIN.
Thanks for your comments,
Markus
--Mark
Thanks,
Markus
(One such reason to do this is to write a wrapper that uses an
alternative
keychain for these keys)
rpm_dirs_found = True
@@ -145,10 +158,17 @@ class RpmIndexer(Indexer):
result = oe.utils.multiprocess_exec(index_cmds, create_index)
if result:
bb.fatal('%s' % ('\n'.join(result)))
-# Copy pubkey to repo
+# Sign repomd
+result = oe.utils.multiprocess_exec(repo_sign_cmds,
create_index)
+if result:
+bb.fatal('%s' % ('\n'.join(result)))
+# Copy pubkey(s) to repo
if self.d.getVar('RPM_SIGN_PACKAGES', True) == '1':
shutil.copy2(self.d.getVar('RPM_GPG_PUBKEY', True),
os.path.join(self.deploy_dir,
'RPM-GPG-KEY-oe'))
+if
[OE-core] [PATCH 1/1] lib/oe/patch: handle patches that delete files with older git
When running git add on a directory with older git versions, deleted files aren't added to what is to be committed unless you explicitly specify the -A option. The result of this is that when applying a patch from a recipe which doesn't apply with git am (and we fall back to applying the patch through other means then git add following by a git commit) these deletes weren't committed with the patch, leaving them sitting deleted but not committed at the end. This should fix test_devtool_modify_native (which unwittingly exercises this scenario by attempting to run devtool modify on apt-native) on machines with older git versions. Signed-off-by: Paul Eggleton paul.eggle...@linux.intel.com --- meta/lib/oe/patch.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/lib/oe/patch.py b/meta/lib/oe/patch.py index c4f042d..108bf1d 100644 --- a/meta/lib/oe/patch.py +++ b/meta/lib/oe/patch.py @@ -415,7 +415,7 @@ class GitApplyTree(PatchTree): # Fall back to patch output = PatchTree._applypatch(self, patch, force, reverse, run) # Add all files -shellcmd = [git, add, -f, .] +shellcmd = [git, add, -f, -A, .] output += runcmd([sh, -c, .join(shellcmd)], self.dir) # Exclude the patches directory shellcmd = [git, reset, HEAD, self.patchdir] -- 2.1.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2 0/1] Add recipe whitelisting class
On Thu, 2015-08-27 at 13:36 +0100, Paul Eggleton wrote: Changes since the RFC version: * Check BPN in addition to PN for matching, to make it easier in the multilib case * Use PNWHITELIST_LAYERS to specify which layers to apply whitelisting to, and consider an empty whitelist value to be no recipes whitelisted (so you can set up empty whitelists for layers not yet in your configuration if you wish to do so). This also makes setting PNWHITELIST without an override practical. * Touch up the comments I've tried various configuration variations and it works fine now, so +1 from me. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] Fix for issue thrown up by devtool QA test
The following changes since commit f07045fcae859c902434062d1725f1348f42d1dd: oeqa/oetest.py: add better package search for hasPackage() (2015-08-26 08:26:37 +0100) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib paule/patchfix http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=paule/patchfix Paul Eggleton (1): lib/oe/patch: handle patches that delete files with older git meta/lib/oe/patch.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.1.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] rt-tests: drop unnecessary added-missing-dependencies.patch
Neither the hackbench target, or the rt-migrate-test target actually depend on librttest.a; drop this unnecessary patch. Signed-off-by: Josh Cartwright jo...@ni.com --- .../files/added-missing-dependencies.patch | 42 -- meta/recipes-rt/rt-tests/rt-tests.inc | 1 - 2 files changed, 43 deletions(-) delete mode 100644 meta/recipes-rt/rt-tests/files/added-missing-dependencies.patch diff --git a/meta/recipes-rt/rt-tests/files/added-missing-dependencies.patch b/meta/recipes-rt/rt-tests/files/added-missing-dependencies.patch deleted file mode 100644 index 0bf768e..000 --- a/meta/recipes-rt/rt-tests/files/added-missing-dependencies.patch +++ /dev/null @@ -1,42 +0,0 @@ -From 3f948f22d9106a2b957d1d430b16a7c51ccfc067 Mon Sep 17 00:00:00 2001 -From: Maxin B. John maxin.j...@enea.com -Date: Tue, 16 Jun 2015 22:53:23 +0200 -Subject: [PATCH] Added missing dependencies - -Upstream-Status: Submitted [linux-rt-users] - -The following targets missed dependency on librttest.a: -rt-migrate-test -hackbench - -Signed-off-by: Jackie Huang jackie.hu...@windriver.com -Signed-off-by: Maxin B. John maxin.j...@enea.com - Makefile | 4 ++-- - 1 file changed, 2 insertions(+), 2 deletions(-) - -diff --git a/Makefile b/Makefile -index a48e759..7a3f192 100644 a/Makefile -+++ b/Makefile -@@ -85,7 +85,7 @@ hwlatdetect: src/hwlatdetect/hwlatdetect.py - chmod +x src/hwlatdetect/hwlatdetect.py - ln -s src/hwlatdetect/hwlatdetect.py hwlatdetect - --rt-migrate-test: rt-migrate-test.o -+rt-migrate-test: rt-migrate-test.o librttest.a - $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $ $(LIBS) - - ptsematest: ptsematest.o librttest.a -@@ -106,7 +106,7 @@ sendme: sendme.o librttest.a - pip_stress: pip_stress.o librttest.a - $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $ $(LIBS) $(RTTESTLIB) - --hackbench: hackbench.o -+hackbench: hackbench.o librttest.a - $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $ $(LIBS) - - librttest.a: rt-utils.o error.o rt-get_cpu.o rt-sched.o --- -1.9.1 - diff --git a/meta/recipes-rt/rt-tests/rt-tests.inc b/meta/recipes-rt/rt-tests/rt-tests.inc index 9a076ad..871db13 100644 --- a/meta/recipes-rt/rt-tests/rt-tests.inc +++ b/meta/recipes-rt/rt-tests/rt-tests.inc @@ -5,7 +5,6 @@ SRCREV = 5f9f1e3fe327440a9d405f4af8feb16ff7a909eb SRC_URI = git://git.kernel.org/pub/scm/linux/kernel/git/clrkwllms/rt-tests.git \ file://0001-rt-tests-Allow-for-user-specified-PYLIB.patch \ file://0002-rt-tests-Break-out-install_hwlatdetect.patch \ - file://added-missing-dependencies.patch \ file://hackbench-fix-error-check.patch \ file://Makefile-fix-gzip-command.patch \ file://fix-re-install-failure.patch \ -- 2.5.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2 1/1] classes/whitelist: add class to allow whitelisting recipes from a layer
On Friday 28 August 2015 09:34:18 Paul Eggleton wrote: On Thursday 27 August 2015 23:07:44 Khem Raj wrote: On Aug 27, 2015, at 5:36 AM, Paul Eggleton paul.eggle...@linux.intel.com wrote: Allow restricting recipes brought from a layer to a specified list. This is similar in operation to blacklist.bbclass, but instead specifies a per-layer whitelist of recipes (matched by PN or BPN) that are able to be built from the layer - anything else is skipped. This is potentially useful where you want to bring in a select set of recipes from a larger layer e.g. meta-oe. For the record, I am not in favor of such feature in OE, Distros can still use BBMASK if they wish to This is significantly easier to use than BBMASK though. (Perhaps that's why you don't like it?) I should expand upon this with a couple of important distinctions: * BBMASK is a list of files to mask out, so it's a blacklist not a whitelist. (Sure, you could probably construct a regex that effectively gives you a whitelist; it probably won't be pretty though.) * BBMASK tells bitbake not to even try reading the masked files, which means if you then request to build any of them (either directly or via a dependency) you'll be told that there's nothing providing that with no explanation as to why. With whitelist.bbclass (and blacklist.bbclass, which whitelist.bbclass is modelled after) we are using SkipPackage/SkipRecipe so you at least get a statement that the recipe was skipped as well as hopefully an explanatory reason as to why. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 4/6] nettle: Add ptests
On 27 August 2015 at 16:06, Jussi Kukkonen jussi.kukko...@intel.com wrote:
Use the nettle testsuite as ptests. Skip sha1-huge-test because
it can take 20 minutes to finish.
Signed-off-by: Jussi Kukkonen jussi.kukko...@intel.com
---
...d-target-to-only-build-tests-not-run-them.patch | 43
++
meta/recipes-support/nettle/files/run-ptest| 36
++
meta/recipes-support/nettle/nettle.inc | 21 ++-
3 files changed, 98 insertions(+), 2 deletions(-)
create mode 100644
meta/recipes-support/nettle/files/Add-target-to-only-build-tests-not-run-them.patch
create mode 100644 meta/recipes-support/nettle/files/run-ptest
diff --git
a/meta/recipes-support/nettle/files/Add-target-to-only-build-tests-not-run-them.patch
b/meta/recipes-support/nettle/files/Add-target-to-only-build-tests-not-run-them.patch
new file mode 100644
index 000..9495d02
--- /dev/null
+++
b/meta/recipes-support/nettle/files/Add-target-to-only-build-tests-not-run-them.patch
@@ -0,0 +1,43 @@
+From 46edf01cc98db9f9feec984897836dfdd26bdc8d Mon Sep 17 00:00:00 2001
+From: Jussi Kukkonen jussi.kukko...@intel.com
+Date: Wed, 12 Aug 2015 23:27:27 +0300
+Subject: [PATCH] Add target to only build tests (not run them)
+
+Upstream-Status: ?
I've changed this to Inappropriate in the branch: it's not a complete
patch for installable tests (that upstream might be interested in) but it's
already useful for us.
+Signed-off-by: Jussi Kukkonen jussi.kukko...@intel.com
+---
+ Makefile.in | 3 +++
+ testsuite/Makefile.in | 2 ++
+ 2 files changed, 5 insertions(+)
+
+diff --git a/Makefile.in b/Makefile.in
+index 08efb7d..7909342 100644
+--- a/Makefile.in
b/Makefile.in
+@@ -55,6 +55,9 @@ clean distclean mostlyclean maintainer-clean tags:
+ echo Making $@ in $d ; (cd $d $(MAKE) $@); done
+ $(MAKE) $@-here
+
++buildtest:
++ echo Making $@ in testsuite ; (cd testsuite $(MAKE) $@)
++
+ check-here:
+ true
+
+diff --git a/testsuite/Makefile.in b/testsuite/Makefile.in
+index 6bc1907..bb65bf0 100644
+--- a/testsuite/Makefile.in
b/testsuite/Makefile.in
+@@ -116,6 +116,8 @@ $(TARGETS) $(EXTRA_TARGETS): testutils.$(OBJEXT)
../nettle-internal.$(OBJEXT) \
+ # data.
+ VALGRIND = valgrind --error-exitcode=1 --leak-check=full
--show-reachable=yes @IF_ASM@ --partial-loads-ok=yes
+
++buildtest: $(TS_ALL)
++
+ # The PATH update is for locating dlls on w*ndows.
+ check: $(TS_ALL)
+ LD_LIBRARY_PATH=../.lib PATH=../.lib:$PATH srcdir=$(srcdir) \
+--
+2.1.4
+
diff --git a/meta/recipes-support/nettle/files/run-ptest
b/meta/recipes-support/nettle/files/run-ptest
new file mode 100644
index 000..b90bed6
--- /dev/null
+++ b/meta/recipes-support/nettle/files/run-ptest
@@ -0,0 +1,36 @@
+#! /bin/sh
+
+cd testsuite
+
+failed=0
+all=0
+
+for f in *-test; do
+if [ $f = sha1-huge-test ] ; then
+echo SKIP: $f (skipped for ludicrous run time)
+continue
+fi
+
+./$f
+case $? in
+0)
+echo PASS: $f
+all=$((all + 1))
+;;
+77)
+echo SKIP: $f
+;;
+*)
+echo FAIL: $f
+failed=$((failed + 1))
+all=$((all + 1))
+;;
+esac
+done
+
+if [ $failed -eq 0 ] ; then
+ echo All $all tests passed
+else
+ echo $failed of $all tests failed
+fi
+
diff --git a/meta/recipes-support/nettle/nettle.inc
b/meta/recipes-support/nettle/nettle.inc
index 0579b6c..fafff6d 100644
--- a/meta/recipes-support/nettle/nettle.inc
+++ b/meta/recipes-support/nettle/nettle.inc
@@ -8,19 +8,36 @@ LIC_FILES_CHKSUM =
file://COPYING.LIB;md5=2d5025d4aa3495befef8f17206a5b0a1 \
DEPENDS += gmp
-SRC_URI = http://www.lysator.liu.se/~nisse/archive/${BP}.tar.gz;
+SRC_URI = http://www.lysator.liu.se/~nisse/archive/${BP}.tar.gz \
+ file://Add-target-to-only-build-tests-not-run-them.patch \
+ file://run-ptest \
+
SRC_URI[md5sum] = 003d5147911317931dd453520eb234a5
SRC_URI[sha256sum] =
bc71ebd43435537d767799e414fce88e521b7278d48c860651216e1fc6555b40
EXTRA_OECONF = --disable-openssl
+inherit autotools ptest
+
do_configure_prepend() {
if [ ! -e ${S}/acinclude.m4 -a -e ${S}/aclocal.m4 ]; then
cp ${S}/aclocal.m4 ${S}/acinclude.m4
fi
}
-inherit autotools
+do_compile_ptest() {
+oe_runmake buildtest
+}
+
+do_install_ptest() {
+install -d ${D}${PTEST_PATH}/testsuite/
+install ${S}/testsuite/gold-bug.txt ${D}${PTEST_PATH}/testsuite/
+install ${S}/testsuite/*-test ${D}${PTEST_PATH}/testsuite/
+# tools can be found in PATH, not in ../tools/
+sed -i -e 's|../tools/||' ${D}${PTEST_PATH}/testsuite/*-test
+install ${B}/testsuite/*-test ${D}${PTEST_PATH}/testsuite/
+}
+
BBCLASSEXTEND = native nativesdk
--
2.1.4
--
Re: [OE-core] [PATCH v2 1/1] classes/whitelist: add class to allow whitelisting recipes from a layer
On Fri, Aug 28, 2015 at 3:07 AM, Khem Raj raj.k...@gmail.com wrote: On Aug 27, 2015, at 5:36 AM, Paul Eggleton paul.eggle...@linux.intel.com wrote: Allow restricting recipes brought from a layer to a specified list. This is similar in operation to blacklist.bbclass, but instead specifies a per-layer whitelist of recipes (matched by PN or BPN) that are able to be built from the layer - anything else is skipped. This is potentially useful where you want to bring in a select set of recipes from a larger layer e.g. meta-oe. For the record, I am not in favor of such feature in OE, Distros can still use BBMASK if they wish to I am also not in favor of the merge of this. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/3] dbus: merge .bb and .inc
On 28/08/15 05:53, Khem Raj wrote: On Thu, Aug 27, 2015 at 2:12 AM, Andrew Shadura andrew.shad...@collabora.co.uk wrote: The split is no longer necessary, and only makes it more complicated to do changes in external layers. Signed-off-by: Andrew Shadura andrew.shad...@collabora.co.uk --- meta/recipes-core/dbus/dbus.inc | 170 - meta/recipes-core/dbus/dbus_1.8.20.bb | 171 +- 2 files changed, 170 insertions(+), 171 deletions(-) delete mode 100644 meta/recipes-core/dbus/dbus.inc can you send patch generated with -M 1 Gives me exact same patch, hmm. -- Cheers, Andrew signature.asc Description: OpenPGP digital signature -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH V3 3/3] runqemu: Define OECORE_MACHINE_SYSROOT on setup_sysroot
Hi Patrick, I do not have much time for a V4 set of patches, but now with all your input I can rework V3 patches on 2.1. Copying Matt and Ricardo, they helped me when porting these patches into poky. They may have other comments. On 08/28/2015 02:29 AM, Patrick Ohly wrote: On Tue, 2015-07-14 at 20:07 +, leonardo.sandoval.gonza...@linux.intel.com wrote: From: Leonardo Sandoval leonardo.sandoval.gonza...@linux.intel.com At least the OVFM (UEFI Firmware for Qemu and KVM) recipe stores the BIOS under $OE_TMPDIR/sysroots/$MACHINE, now defined as OECORE_MACHINE_SYSROOT. The latter is used when searching BIOS, VGA BIOS and keymaps. As a example, to boot a OVFM BIOS, one can run the following command: $ runqemu qemux86-64 core-image-minimal \ biosdir=usr/share/ovmf \ biosfilename=bios.bin \ nographic Note the bios* parameters: these two are needed to specify the subfolder (parent folder is OECORE_MACHINE_SYSROOT) and BIOS filename (without it, it picks a BIOS named bios-256k.bin). While researching the nvram support question I came across the ovmf whitepaper [1] showing how to use OVMF via -drive if=pflash,format=raw,file=fedora.flash (where fedora.flash is a per-vm copy of OVMF.fd = bios.bin in the sysroot). I kept wondering why you were using -bios bios.bin instead of the -drive method, and how that would affect nvram support. Then I found a pretty clear statement by Laszlo Ersek, one of the OVMF co-maintainers, saying [2] that -bios and the nvram support possible with it (storing in an NvRam file in the EFI boot partition) are a kludge that should not be used anymore. So in other words, this particular patch needs further work. Perhaps add an ovmf keyword (selecting the bios.bin as pflash drive), file name handling (treat anything ending in .bin or .fd as pflash, supporting more than one) and a OVMF env variable with a corresponding colon separated list of pflash files? I also wonder about the bios.bin name and the .bin suffix. I think it would be better to stick with the upstream convention and just install the file in the sysroot as OVMF.fd. This simplifies the file name handling such that only .fd is special. Note that the upstream discussion was about per-vm nvram storage. I think in the context of runqemu it is okay to have a single file per build configuration, because effectively we are creating a single machine with one OS image. What's less nice is that the sysroot will get modified when using bios.bin as pflash drive. Resetting the nvram needs to be done with bitbake -c clean ovmf bitbake ovmf. Both is not obvious. Perhaps if runqemu picks up the file automatically from the sysroot (the ovmf keyword usage), it should make a copy in tmp (on first run) and then use that copy instead? [1] http://www.linux-kvm.org/downloads/lersek/ovmf-whitepaper-c770f8c.txt [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764918#47 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/3] dbus: merge .bb and .inc
Hello again, By the way, Khem, what's new about your systemd update patches? I have more patches for dbus recipe, but they depend on a newer systemd, so I don't send them in yet. -- Cheers, Andrew signature.asc Description: OpenPGP digital signature -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH][fido] icu: CVE-2014-8146-CVE-2014-8147
CVE-2014-8146 icu: heap overflow via incorrect isolateCount
CVE-2014-8147 icu: integer truncation in the resolveImplicitLevels function
References:
[1] https://github.com/pedrib/PoC/raw/master/generic/i-c-u-fail.7z
[2] https://www.kb.cert.org/vuls/id/602540
[3] http://bugs.icu-project.org/trac/changeset/37080
[4] http://bugs.icu-project.org/trac/changeset/37162
Signed-off-by: Sona Sarmadi sona.sarm...@enea.com
---
.../icu/icu/icu-CVE-2014-8146-CVE-2014-8147.patch | 49 ++
meta/recipes-support/icu/icu_54.1.bb | 1 +
2 files changed, 50 insertions(+)
create mode 100644
meta/recipes-support/icu/icu/icu-CVE-2014-8146-CVE-2014-8147.patch
diff --git a/meta/recipes-support/icu/icu/icu-CVE-2014-8146-CVE-2014-8147.patch
b/meta/recipes-support/icu/icu/icu-CVE-2014-8146-CVE-2014-8147.patch
new file mode 100644
index 000..cf32d13c
--- /dev/null
+++ b/meta/recipes-support/icu/icu/icu-CVE-2014-8146-CVE-2014-8147.patch
@@ -0,0 +1,49 @@
+ICU: CVE-2014-8146-CVE-2014-8147
+
+CVE-2014-8146 icu: heap overflow via incorrect isolateCount
+CVE-2014-8147 icu: integer truncation in the resolveImplicitLevels function
+
+References:
+[1] https://github.com/pedrib/PoC/raw/master/generic/i-c-u-fail.7z
+[2] https://www.kb.cert.org/vuls/id/602540
+[3] http://bugs.icu-project.org/trac/changeset/37080
+[4] http://bugs.icu-project.org/trac/changeset/37162
+
+Upstream-Status: Backport
+
+Signed-off-by: Sona Sarmadi sona.sarm...@enea.com
+---
+diff -ruN a/common/ubidi.c b/common/ubidi.c
+--- a/common/ubidi.c 2014-10-03 18:11:20.0 +0200
b/common/ubidi.c 2015-08-28 08:22:39.455906194 +0200
+@@ -2138,7 +2138,7 @@
+ /* The isolates[] entries contain enough information to
+resume the bidi algorithm in the same state as it was
+when it was interrupted by an isolate sequence. */
+-if(dirProps[start]==PDI) {
++if(dirProps[start]==PDI pBiDi-isolateCount = 0) {
+ levState.startON=pBiDi-isolates[pBiDi-isolateCount].startON;
+ start1=pBiDi-isolates[pBiDi-isolateCount].start1;
+ stateImp=pBiDi-isolates[pBiDi-isolateCount].stateImp;
+diff -ruN a/common/ubidiimp.h b/common/ubidiimp.h
+--- a/common/ubidiimp.h2014-10-03 18:11:16.0 +0200
b/common/ubidiimp.h2015-08-28 08:28:24.069163845 +0200
+@@ -1,7 +1,7 @@
+ /*
+ **
+ *
+-* Copyright (C) 1999-2014, International Business Machines
++* Copyright (C) 1999-2015, International Business Machines
+ * Corporation and others. All Rights Reserved.
+ *
+ **
+@@ -184,8 +184,8 @@
+ typedef struct Isolate {
+ int32_t startON;
+ int32_t start1;
++int32_t state;
+ int16_t stateImp;
+-int16_t state;
+ } Isolate;
+
+ typedef struct Run {
diff --git a/meta/recipes-support/icu/icu_54.1.bb
b/meta/recipes-support/icu/icu_54.1.bb
index 45b5cb6..9f10beb 100644
--- a/meta/recipes-support/icu/icu_54.1.bb
+++ b/meta/recipes-support/icu/icu_54.1.bb
@@ -11,6 +11,7 @@ ICU_PV = ${@icu_download_version(d)}
BASE_SRC_URI =
http://download.icu-project.org/files/icu4c/${PV}/icu4c-${ICU_PV}-src.tgz;
SRC_URI = ${BASE_SRC_URI} \
file://icu-pkgdata-large-cmd.patch \
+ file://icu-CVE-2014-8146-CVE-2014-8147.patch \
SRC_URI_append_class-target = \
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2 1/1] classes/whitelist: add class to allow whitelisting recipes from a layer
On Friday 28 August 2015 10:55:41 Otavio Salvador wrote: On Fri, Aug 28, 2015 at 3:07 AM, Khem Raj raj.k...@gmail.com wrote: On Aug 27, 2015, at 5:36 AM, Paul Eggleton paul.eggle...@linux.intel.com wrote: Allow restricting recipes brought from a layer to a specified list. This is similar in operation to blacklist.bbclass, but instead specifies a per-layer whitelist of recipes (matched by PN or BPN) that are able to be built from the layer - anything else is skipped. This is potentially useful where you want to bring in a select set of recipes from a larger layer e.g. meta-oe. For the record, I am not in favor of such feature in OE, Distros can still use BBMASK if they wish to I am also not in favor of the merge of this. Do you have a practical alternative that has less downsides? Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/8] Recipe updates
This patchset contains various recipe version updates that have accumulated;
I have also deprectead upstream_tracking.inc and moved its contents to recipes.
The same thing will be done later with package_regex.inc and maintainers.inc.
Also no update reasons are added for rpm, db and e2fsprogs.
The following changes since commit 393bd7496d71eb101f21234c1233a2d18fd2c73e:
oeqa/oetest.py: add better package search for hasPackage() (2015-08-26
08:28:06 +0100)
are available in the git repository at:
git://git.yoctoproject.org/poky-contrib akanavin/package-version-updates
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=akanavin/package-version-updates
Alexander Kanavin (8):
upstream_tracking.inc: deprecate and move contents to recipes
dpkg: update to 1.18.2
dropbear: update to 2015.68
libnotify: don't inherit unnecessary distro_features_check
e2fsprogs: explain why there is no update for now
package_regex.inc: updates to improve upstream tracking
ccache: update to 3.2.3
cmake: update to 3.3.1
meta/conf/distro/include/package_regex.inc | 8 +++-
meta/conf/distro/include/upstream_tracking.inc | 18 +
.../recipes-core/base-passwd/base-passwd_3.5.29.bb | 2 +
meta/recipes-core/dropbear/dropbear.inc| 2 +-
meta/recipes-core/dropbear/dropbear_2015.67.bb | 4 --
meta/recipes-core/dropbear/dropbear_2015.68.bb | 4 ++
meta/recipes-devtools/ccache/ccache.inc| 4 +-
meta/recipes-devtools/ccache/ccache_3.1.11.bb | 7
meta/recipes-devtools/ccache/ccache_3.2.3.bb | 6 +++
...cmake-native_3.2.2.bb = cmake-native_3.3.1.bb} | 3 --
meta/recipes-devtools/cmake/cmake.inc | 3 ++
.../cmake/{cmake_3.2.2.bb = cmake_3.3.1.bb} | 3 --
meta/recipes-devtools/dpkg/dpkg.inc| 2 +-
...-do_package_write_deb-we-have-trees-of-h.patch} | 37 +++---
...nux-wrs-kernel-version-which-has-characte.patch | 38 ++
...insts-expect-D-to-be-set-when-running-in.patch} | 29 +-
...-function-doesn-t-work-properly-for-all-s.patch | 31 +++
...tch = 0005-dpkg-compiler.m4-remove-Wvla.patch} | 26 +++--
.../dpkg/dpkg/check_snprintf.patch | 34
.../recipes-devtools/dpkg/dpkg/check_version.patch | 28 --
.../dpkg/dpkg/fix-timestamps.patch | 21 --
meta/recipes-devtools/dpkg/dpkg/tarfix.patch | 45 --
.../dpkg/{dpkg_1.17.25.bb = dpkg_1.18.2.bb} | 14 +++
.../recipes-devtools/e2fsprogs/e2fsprogs_1.42.9.bb | 1 +
.../python/python-pygobject_2.28.3.bb | 3 ++
meta/recipes-devtools/rpm/rpm_5.4.14.bb| 2 +
meta/recipes-devtools/unfs3/unfs3_0.9.22.r490.bb | 5 +++
.../recipes-extended/chkconfig/chkconfig_1.3.58.bb | 2 +
meta/recipes-gnome/libnotify/libnotify_0.7.6.bb| 2 +-
.../ttf-fonts/liberation-fonts_1.04.bb | 2 +
meta/recipes-multimedia/tremor/tremor_20150107.bb | 5 +++
.../createrepo/createrepo_0.4.11.bb| 2 +
meta/recipes-support/db/db_6.0.30.bb | 2 +
33 files changed, 185 insertions(+), 210 deletions(-)
delete mode 100644 meta/recipes-core/dropbear/dropbear_2015.67.bb
create mode 100644 meta/recipes-core/dropbear/dropbear_2015.68.bb
delete mode 100644 meta/recipes-devtools/ccache/ccache_3.1.11.bb
create mode 100644 meta/recipes-devtools/ccache/ccache_3.2.3.bb
rename meta/recipes-devtools/cmake/{cmake-native_3.2.2.bb =
cmake-native_3.3.1.bb} (72%)
rename meta/recipes-devtools/cmake/{cmake_3.2.2.bb = cmake_3.3.1.bb} (92%)
rename meta/recipes-devtools/dpkg/dpkg/{tar-error-code.patch =
0001-When-running-do_package_write_deb-we-have-trees-of-h.patch} (60%)
create mode 100644
meta/recipes-devtools/dpkg/dpkg/0002-Adapt-to-linux-wrs-kernel-version-which-has-characte.patch
rename meta/recipes-devtools/dpkg/dpkg/{preinst.patch =
0003-Our-pre-postinsts-expect-D-to-be-set-when-running-in.patch} (59%)
create mode 100644
meta/recipes-devtools/dpkg/dpkg/0004-The-lutimes-function-doesn-t-work-properly-for-all-s.patch
rename meta/recipes-devtools/dpkg/dpkg/{no-vla-warning.patch =
0005-dpkg-compiler.m4-remove-Wvla.patch} (58%)
delete mode 100644 meta/recipes-devtools/dpkg/dpkg/check_snprintf.patch
delete mode 100644 meta/recipes-devtools/dpkg/dpkg/check_version.patch
delete mode 100644 meta/recipes-devtools/dpkg/dpkg/fix-timestamps.patch
delete mode 100644 meta/recipes-devtools/dpkg/dpkg/tarfix.patch
rename meta/recipes-devtools/dpkg/{dpkg_1.17.25.bb = dpkg_1.18.2.bb} (49%)
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/8] dpkg: update to 1.18.2
check_snprintf.patch has been dropped, because it seems to fix a problem
that doesn't anymore exist, and doesn't have any description of what the
problem was and how was it fixed.
tarfix.patch has been merged upstream.
The rest of the patches have been rebased to the new upstream release
Signed-off-by: Alexander Kanavin alexander.kana...@linux.intel.com
---
meta/recipes-devtools/dpkg/dpkg.inc| 2 +-
...-do_package_write_deb-we-have-trees-of-h.patch} | 37 +++---
...nux-wrs-kernel-version-which-has-characte.patch | 38 ++
...insts-expect-D-to-be-set-when-running-in.patch} | 29 +-
...-function-doesn-t-work-properly-for-all-s.patch | 31 +++
...tch = 0005-dpkg-compiler.m4-remove-Wvla.patch} | 26 +++--
.../dpkg/dpkg/check_snprintf.patch | 34
.../recipes-devtools/dpkg/dpkg/check_version.patch | 28 --
.../dpkg/dpkg/fix-timestamps.patch | 21 --
meta/recipes-devtools/dpkg/dpkg/tarfix.patch | 45 --
.../dpkg/{dpkg_1.17.25.bb = dpkg_1.18.2.bb} | 14 +++
11 files changed, 133 insertions(+), 172 deletions(-)
rename meta/recipes-devtools/dpkg/dpkg/{tar-error-code.patch =
0001-When-running-do_package_write_deb-we-have-trees-of-h.patch} (60%)
create mode 100644
meta/recipes-devtools/dpkg/dpkg/0002-Adapt-to-linux-wrs-kernel-version-which-has-characte.patch
rename meta/recipes-devtools/dpkg/dpkg/{preinst.patch =
0003-Our-pre-postinsts-expect-D-to-be-set-when-running-in.patch} (59%)
create mode 100644
meta/recipes-devtools/dpkg/dpkg/0004-The-lutimes-function-doesn-t-work-properly-for-all-s.patch
rename meta/recipes-devtools/dpkg/dpkg/{no-vla-warning.patch =
0005-dpkg-compiler.m4-remove-Wvla.patch} (58%)
delete mode 100644 meta/recipes-devtools/dpkg/dpkg/check_snprintf.patch
delete mode 100644 meta/recipes-devtools/dpkg/dpkg/check_version.patch
delete mode 100644 meta/recipes-devtools/dpkg/dpkg/fix-timestamps.patch
delete mode 100644 meta/recipes-devtools/dpkg/dpkg/tarfix.patch
rename meta/recipes-devtools/dpkg/{dpkg_1.17.25.bb = dpkg_1.18.2.bb} (49%)
diff --git a/meta/recipes-devtools/dpkg/dpkg.inc
b/meta/recipes-devtools/dpkg/dpkg.inc
index 5db1fde..6eec2cde 100644
--- a/meta/recipes-devtools/dpkg/dpkg.inc
+++ b/meta/recipes-devtools/dpkg/dpkg.inc
@@ -4,7 +4,7 @@ SECTION = base
SRC_URI = ${DEBIAN_MIRROR}/main/d/dpkg/dpkg_${PV}.tar.xz
-SRC_URI_append_class-native = file://tar-error-code.patch
+SRC_URI_append_class-native =
file://0001-When-running-do_package_write_deb-we-have-trees-of-h.patch
DEPENDS = zlib bzip2 perl ncurses
DEPENDS_class-native = bzip2-replacement-native zlib-native
virtual/update-alternatives-native gettext-native perl-native
diff --git a/meta/recipes-devtools/dpkg/dpkg/tar-error-code.patch
b/meta/recipes-devtools/dpkg/dpkg/0001-When-running-do_package_write_deb-we-have-trees-of-h.patch
similarity index 60%
rename from meta/recipes-devtools/dpkg/dpkg/tar-error-code.patch
rename to
meta/recipes-devtools/dpkg/dpkg/0001-When-running-do_package_write_deb-we-have-trees-of-h.patch
index dcde508..6967ef4 100644
--- a/meta/recipes-devtools/dpkg/dpkg/tar-error-code.patch
+++
b/meta/recipes-devtools/dpkg/dpkg/0001-When-running-do_package_write_deb-we-have-trees-of-h.patch
@@ -1,7 +1,10 @@
-When running do_package_write_deb, we have trees of hardlinked files
-such as the dbg source files in ${PN}-dbg. If something makes another
-copy of one of those files (or deletes one), the number of links a file
-has changes and tar can notice this, e.g.:
+From d14ffd786993da60ca84c4812da8a6594a8c764e Mon Sep 17 00:00:00 2001
+From: Alexander Kanavin alex.kana...@gmail.com
+Date: Wed, 26 Aug 2015 15:48:13 +0300
+Subject: [PATCH 1/5] When running do_package_write_deb, we have trees of
+ hardlinked files such as the dbg source files in ${PN}-dbg. If something
+ makes another copy of one of those files (or deletes one), the number of
+ links a file has changes and tar can notice this, e.g.:
| DEBUG: Executing python function do_package_deb
| dpkg-deb: building package `sed-ptest' in
`/media/build1/poky/build/tmp/work/i586-poky-linux/sed/4.2.2-r0/deploy-debs/i586/sed-ptest_4.2.2-r0.3_i386.deb'.
@@ -15,13 +18,16 @@ place to avoid that kind of issue).
Upstream-Status: Inappropriate
RP 2015/3/27
+---
+ dpkg-deb/build.c | 11 ---
+ 1 file changed, 8 insertions(+), 3 deletions(-)
-Index: dpkg-1.17.21/dpkg-deb/build.c
-===
dpkg-1.17.21.orig/dpkg-deb/build.c
-+++ dpkg-1.17.21/dpkg-deb/build.c
-@@ -398,7 +398,7 @@ do_build(const char *const *argv)
- bool subdir;
+diff --git a/dpkg-deb/build.c b/dpkg-deb/build.c
+index ea3d861..1589927 100644
+--- a/dpkg-deb/build.c
b/dpkg-deb/build.c
+@@ -458,7 +458,7 @@ do_build(const char *const *argv)
+ char *debar;
char *tfbuf;
int arfd;
- int p1[2], p2[2], gzfd;
@@ -29,10
[OE-core] [PATCH 6/8] package_regex.inc: updates to improve upstream tracking
Signed-off-by: Alexander Kanavin alexander.kana...@linux.intel.com
---
meta/conf/distro/include/package_regex.inc | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/meta/conf/distro/include/package_regex.inc
b/meta/conf/distro/include/package_regex.inc
index 0c29ade..df384e2 100644
--- a/meta/conf/distro/include/package_regex.inc
+++ b/meta/conf/distro/include/package_regex.inc
@@ -43,6 +43,7 @@ REGEX_pn-iputils=iputils-(?Ppvers\d+).tar
REGEX_pn-nettle = nettle-(?Ppver\d+(\.\d+)+)\.tar
REGEX_pn-cairo = cairo-(?Ppver\d+(\.\d+)+)\.tar
+REGEX_pn-cmake = cmake-(?Ppver\d+(\.\d+)+)\.tar
# Exclude NC versions which lack AES encryption
REGEX_pn-db = db-(?Ppver\d+\.\d+(\.\d+)?).tar
@@ -199,6 +200,9 @@ GITTAGREGEX_pn-sgmlspl = (?Ppver(\d+(\.\d+)+))
# Exclude x.99.x versions
GITTAGREGEX_pn-mx-1.0 = (?Ppver^\d+(\.(?!99)\d+)+)
+# Blacklist a bogus tag
+GITTAGREGEX_pn-file = FILE(?Ppver(?!6_23).+)
+
# GNOME related.
#
# GNOME2_STABLE picks stable releases in the 2.x series (so not 2.90 onwards,
@@ -206,8 +210,8 @@ GITTAGREGEX_pn-mx-1.0 = (?Ppver^\d+(\.(?!99)\d+)+)
#
# GNOME_STABLE picks the latest stable release.
-GNOME2_STABLE = (?Ppver2\.([0-8]*[02468])+\.\d+)
-GNOME_STABLE = (?Ppver\d+\.(\d*[02468])+\.\d+)
+GNOME2_STABLE = (?Ppver2\.([0-8]*[02468])+(\.\d+)+)
+GNOME_STABLE = (?Ppver\d+\.(\d*[02468])+(\.\d+)+)
REGEX_pn-glib-2.0 = ${GNOME_STABLE}
REGEX_pn-atk = ${GNOME_STABLE}
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/8] upstream_tracking.inc: deprecate and move contents to recipes
No-update reasons and manual version checks should be in the recipes
themselves because otherwise they're prone to getting out of date.
Signed-off-by: Alexander Kanavin alexander.kana...@linux.intel.com
---
meta/conf/distro/include/upstream_tracking.inc | 18 ++
meta/recipes-core/base-passwd/base-passwd_3.5.29.bb| 2 ++
.../recipes-devtools/python/python-pygobject_2.28.3.bb | 3 +++
meta/recipes-devtools/rpm/rpm_5.4.14.bb| 2 ++
meta/recipes-devtools/unfs3/unfs3_0.9.22.r490.bb | 5 +
meta/recipes-extended/chkconfig/chkconfig_1.3.58.bb| 2 ++
.../ttf-fonts/liberation-fonts_1.04.bb | 2 ++
meta/recipes-multimedia/tremor/tremor_20150107.bb | 5 +
meta/recipes-support/createrepo/createrepo_0.4.11.bb | 2 ++
meta/recipes-support/db/db_6.0.30.bb | 2 ++
10 files changed, 27 insertions(+), 16 deletions(-)
diff --git a/meta/conf/distro/include/upstream_tracking.inc
b/meta/conf/distro/include/upstream_tracking.inc
index 996d9e0..e2a5e6c 100644
--- a/meta/conf/distro/include/upstream_tracking.inc
+++ b/meta/conf/distro/include/upstream_tracking.inc
@@ -1,3 +1,5 @@
+# NOTE: THIS FILE IS DEPRECATED. Please add new entries to the recipes
themselves.
+#
# upstream_tracking.inc - This file contains data that tracks the
# upstream project associated with a given recipe. This list is needed
# for recipes that version information can not be automagically discovered.
@@ -20,19 +22,3 @@
# the information in this file. So for existing recipes that we can get
# from the Recipe reporting system, the entries here can be removed.
#
-
-# SVN support isn't implemented
-# Also a new tarball release (or SVN tag) hasn't happened in a long time
-RECIPE_UPSTREAM_VERSION_pn-unfs3=0.9.22.r495
-RECIPE_UPSTREAM_DATE_pn-unfs3=Feb 05, 2015
-CHECK_DATE_pn-unfs3 = Jun 10, 2015
-
-# NO UPDATE REASONS
-RECIPE_NO_UPDATE_REASON_pn-base-passwd = Version 3.5.38 requires cdebconf for
update-passwd utility
-RECIPE_NO_UPDATE_REASON_pn-chkconfig = Version 1.5 requires selinux
-RECIPE_NO_UPDATE_REASON_pn-createrepo = Versions after 0.9.* use YUM, so we
hold at 0.4.11
-RECIPE_NO_UPDATE_REASON_pn-jpeg = webkit-gtk 1.8.3 doesn't work with jpeg 9
-RECIPE_NO_UPDATE_REASON_pn-liberation-fonts = 2.x depends on fontforge
package, which is not yet provided in oe-core
-RECIPE_NO_UPDATE_REASON_pn-pkgconfig = removes glib-conf, adds circular
depends
-RECIPE_NO_UPDATE_REASON_pn-python-pygobject = Newer versions of
python-pygobject depend on gobject-introspection which doesn't cross-compile
-RECIPE_NO_UPDATE_REASON_pn-webkit-gtk = = 1.10.2 needs ruby
diff --git a/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb
b/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb
index a8bd7c4..ac9bd81 100644
--- a/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb
+++ b/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb
@@ -4,6 +4,8 @@ SECTION = base
LICENSE = GPLv2+
LIC_FILES_CHKSUM = file://COPYING;md5=eb723b61539feef013de476e68b5c50a
+RECIPE_NO_UPDATE_REASON = Version 3.5.38 requires cdebconf for update-passwd
utility
+
SRC_URI =
https://launchpad.net/debian/+archive/primary/+files/${BPN}_${PV}.tar.gz \
file://add_shutdown.patch \
file://nobash.patch \
diff --git a/meta/recipes-devtools/python/python-pygobject_2.28.3.bb
b/meta/recipes-devtools/python/python-pygobject_2.28.3.bb
index f4359bb..81d37b4 100644
--- a/meta/recipes-devtools/python/python-pygobject_2.28.3.bb
+++ b/meta/recipes-devtools/python/python-pygobject_2.28.3.bb
@@ -1,6 +1,9 @@
SUMMARY = Python GObject bindings
SECTION = devel/python
LICENSE = LGPLv2.1
+
+RECIPE_NO_UPDATE_REASON = Newer versions of python-pygobject depend on
gobject-introspection which doesn't cross-compile
+
LIC_FILES_CHKSUM = file://COPYING;md5=a916467b91076e631dd8edb7424769c7
DEPENDS = python python-pygobject-native libffi glib-2.0
DEPENDS_class-native = python-native libffi-native glib-2.0-native
diff --git a/meta/recipes-devtools/rpm/rpm_5.4.14.bb
b/meta/recipes-devtools/rpm/rpm_5.4.14.bb
index 1f4d9d2..1f9a4bd 100644
--- a/meta/recipes-devtools/rpm/rpm_5.4.14.bb
+++ b/meta/recipes-devtools/rpm/rpm_5.4.14.bb
@@ -5,6 +5,8 @@ verifying, querying, and updating software packages. Each
software \
package consists of an archive of files along with information about \
the package like its version, a description, etc.
+RECIPE_NO_UPDATE_REASON = 5.4.15 has a package database issue:
http://lists.openembedded.org/pipermail/openembedded-core/2015-August/109187.html;
+
SUMMARY_${PN}-libs = Libraries for manipulating RPM packages
DESCRIPTION_${PN}-libs = This package contains the RPM shared libraries.
diff --git a/meta/recipes-devtools/unfs3/unfs3_0.9.22.r490.bb
b/meta/recipes-devtools/unfs3/unfs3_0.9.22.r490.bb
index f87b170..45cf545 100644
--- a/meta/recipes-devtools/unfs3/unfs3_0.9.22.r490.bb
+++ b/meta/recipes-devtools/unfs3/unfs3_0.9.22.r490.bb
@@ -3,6 +3,11 @@ SECTION
[OE-core] [PATCH 5/8] e2fsprogs: explain why there is no update for now
Signed-off-by: Alexander Kanavin alexander.kana...@linux.intel.com --- meta/recipes-devtools/e2fsprogs/e2fsprogs_1.42.9.bb | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.42.9.bb b/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.42.9.bb index 70085e3..97e29c8 100644 --- a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.42.9.bb +++ b/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.42.9.bb @@ -1,5 +1,6 @@ require e2fsprogs.inc +RECIPE_NO_UPDATE_REASON = Updating backported patches to 1.42.13 is too much pain. Let's wait until 1.43 is released. SRC_URI += file://acinclude.m4 \ file://remove.ldconfig.call.patch \ -- 2.1.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/8] dropbear: update to 2015.68
LICENSE checksum has changed because the copyright year was changed
from 2014 to 2015 in it:
https://github.com/mkj/dropbear/commit/19e1afbd1ca6d306166ce74bcd6c6889f8d196f3
Signed-off-by: Alexander Kanavin alexander.kana...@linux.intel.com
---
meta/recipes-core/dropbear/dropbear.inc| 2 +-
meta/recipes-core/dropbear/dropbear_2015.67.bb | 4
meta/recipes-core/dropbear/dropbear_2015.68.bb | 4
3 files changed, 5 insertions(+), 5 deletions(-)
delete mode 100644 meta/recipes-core/dropbear/dropbear_2015.67.bb
create mode 100644 meta/recipes-core/dropbear/dropbear_2015.68.bb
diff --git a/meta/recipes-core/dropbear/dropbear.inc
b/meta/recipes-core/dropbear/dropbear.inc
index e187d04..a2c736e 100644
--- a/meta/recipes-core/dropbear/dropbear.inc
+++ b/meta/recipes-core/dropbear/dropbear.inc
@@ -5,7 +5,7 @@ SECTION = console/network
# some files are from other projects and have others license terms:
# public domain, OpenSSH 3.5p1, OpenSSH3.6.1p2, PuTTY
LICENSE = MIT BSD-3-Clause BSD-2-Clause PD
-LIC_FILES_CHKSUM = file://LICENSE;md5=e3a1b9604afd1648b28b0c6f1709e9f4
+LIC_FILES_CHKSUM = file://LICENSE;md5=a5ec40cafba26fc4396d0b550f824e01
DEPENDS = zlib
RPROVIDES_${PN} = ssh sshd
diff --git a/meta/recipes-core/dropbear/dropbear_2015.67.bb
b/meta/recipes-core/dropbear/dropbear_2015.67.bb
deleted file mode 100644
index 5f7fe7b..000
--- a/meta/recipes-core/dropbear/dropbear_2015.67.bb
+++ /dev/null
@@ -1,4 +0,0 @@
-require dropbear.inc
-
-SRC_URI[md5sum] = e967e320344cd4bfebe321e3ab8514d6
-SRC_URI[sha256sum] =
7e690594645dfde5787065c78a5d2e4d15e288babfa06e140197ce05f698c8e5
diff --git a/meta/recipes-core/dropbear/dropbear_2015.68.bb
b/meta/recipes-core/dropbear/dropbear_2015.68.bb
new file mode 100644
index 000..1b749d7
--- /dev/null
+++ b/meta/recipes-core/dropbear/dropbear_2015.68.bb
@@ -0,0 +1,4 @@
+require dropbear.inc
+
+SRC_URI[md5sum] = 7664ac10f7cc2301c530eb80c756fc5d
+SRC_URI[sha256sum] =
55ea7c1e904ffe4b1cdbe1addca8291a2533d7d285fd22ac33608e9502a62446
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 4/8] libnotify: don't inherit unnecessary distro_features_check
Signed-off-by: Alexander Kanavin alexander.kana...@linux.intel.com --- meta/recipes-gnome/libnotify/libnotify_0.7.6.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-gnome/libnotify/libnotify_0.7.6.bb b/meta/recipes-gnome/libnotify/libnotify_0.7.6.bb index 5d7b4ce..c5788c8 100644 --- a/meta/recipes-gnome/libnotify/libnotify_0.7.6.bb +++ b/meta/recipes-gnome/libnotify/libnotify_0.7.6.bb @@ -5,7 +5,7 @@ LIC_FILES_CHKSUM = file://COPYING;md5=7fbc338309ac38fefcd64b04bb903e34 DEPENDS = dbus gtk+3 dbus-glib -inherit gnomebase distro_features_check gtk-doc +inherit gnomebase gtk-doc SRC_URI[archive.md5sum] = a4997019d08f46f3bf57b78e6f795a59 SRC_URI[archive.sha256sum] = 0ef61ca400d30e28217979bfa0e73a7406b19c32dd76150654ec5b2bdf47d837 -- 2.1.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 7/8] ccache: update to 3.2.3
The LICENSE checksum has changed because of updated copyright years.
SRC_URI has been changed to git, because upstream tarball is broken
(includes configure.ac but not .m4 files it depends on).
Signed-off-by: Alexander Kanavin alexander.kana...@linux.intel.com
---
meta/recipes-devtools/ccache/ccache.inc | 4 +++-
meta/recipes-devtools/ccache/ccache_3.1.11.bb | 7 ---
meta/recipes-devtools/ccache/ccache_3.2.3.bb | 6 ++
3 files changed, 9 insertions(+), 8 deletions(-)
delete mode 100644 meta/recipes-devtools/ccache/ccache_3.1.11.bb
create mode 100644 meta/recipes-devtools/ccache/ccache_3.2.3.bb
diff --git a/meta/recipes-devtools/ccache/ccache.inc
b/meta/recipes-devtools/ccache/ccache.inc
index 087cb7d..4790021 100644
--- a/meta/recipes-devtools/ccache/ccache.inc
+++ b/meta/recipes-devtools/ccache/ccache.inc
@@ -9,7 +9,9 @@ LICENSE = GPLv3+
DEPENDS = zlib
-SRC_URI = http://samba.org/ftp/ccache/ccache-${PV}.tar.xz;
+SRC_URI = git://git.samba.org/ccache.git
+
+S = ${WORKDIR}/git
inherit autotools
diff --git a/meta/recipes-devtools/ccache/ccache_3.1.11.bb
b/meta/recipes-devtools/ccache/ccache_3.1.11.bb
deleted file mode 100644
index 7696003..000
--- a/meta/recipes-devtools/ccache/ccache_3.1.11.bb
+++ /dev/null
@@ -1,7 +0,0 @@
-require ccache.inc
-
-LICENSE = GPLv3+
-LIC_FILES_CHKSUM = file://LICENSE.txt;md5=80e92ec45d4fca91f127864fb9e5d932
-
-SRC_URI[md5sum] = 0f6df80c8941d9020a1fd5df5ad57dd7
-SRC_URI[sha256sum] =
60e9f3f1e60f528cfce910f3224bcc698029320f6ab77ec09a7b46bda2bc678e
diff --git a/meta/recipes-devtools/ccache/ccache_3.2.3.bb
b/meta/recipes-devtools/ccache/ccache_3.2.3.bb
new file mode 100644
index 000..06d04fc
--- /dev/null
+++ b/meta/recipes-devtools/ccache/ccache_3.2.3.bb
@@ -0,0 +1,6 @@
+require ccache.inc
+
+LICENSE = GPLv3+
+LIC_FILES_CHKSUM = file://LICENSE.txt;md5=b3c337e7664559a789d9f7a93e5283c1
+
+SRCREV = 4cad46e8ee0053144bb00919f0dadd20c1f87013
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 8/8] cmake: update to 3.3.1
Share tarball checksums between cmake and cmake-native via cmake.inc.
Signed-off-by: Alexander Kanavin alexander.kana...@linux.intel.com
---
.../cmake/{cmake-native_3.2.2.bb = cmake-native_3.3.1.bb} | 3 ---
meta/recipes-devtools/cmake/cmake.inc | 3 +++
meta/recipes-devtools/cmake/{cmake_3.2.2.bb = cmake_3.3.1.bb} | 3 ---
3 files changed, 3 insertions(+), 6 deletions(-)
rename meta/recipes-devtools/cmake/{cmake-native_3.2.2.bb =
cmake-native_3.3.1.bb} (72%)
rename meta/recipes-devtools/cmake/{cmake_3.2.2.bb = cmake_3.3.1.bb} (92%)
diff --git a/meta/recipes-devtools/cmake/cmake-native_3.2.2.bb
b/meta/recipes-devtools/cmake/cmake-native_3.3.1.bb
similarity index 72%
rename from meta/recipes-devtools/cmake/cmake-native_3.2.2.bb
rename to meta/recipes-devtools/cmake/cmake-native_3.3.1.bb
index 17e9e2c..cb4e749 100644
--- a/meta/recipes-devtools/cmake/cmake-native_3.2.2.bb
+++ b/meta/recipes-devtools/cmake/cmake-native_3.3.1.bb
@@ -8,9 +8,6 @@ SRC_URI += \
file://cmlibarchive-disable-ext2fs.patch \
-SRC_URI[md5sum] = 2da57308071ea98b10253a87d2419281
-SRC_URI[sha256sum] =
ade94e6e36038774565f2aed8866415443444fb7a362eb0ea5096e40d5407c78
-
# Disable ccmake since we don't depend on ncurses
CMAKE_EXTRACONF = \
-DBUILD_CursesDialog=0 \
diff --git a/meta/recipes-devtools/cmake/cmake.inc
b/meta/recipes-devtools/cmake/cmake.inc
index d1cb7ab..57e93ac 100644
--- a/meta/recipes-devtools/cmake/cmake.inc
+++ b/meta/recipes-devtools/cmake/cmake.inc
@@ -16,6 +16,9 @@ SRC_URI =
http://www.cmake.org/files/v${CMAKE_MAJOR_VERSION}/cmake-${PV}.tar.gz
file://qt4-fail-silent.patch \
+SRC_URI[md5sum] = 52638576f4e1e621fed6c3410d3a1b12
+SRC_URI[sha256sum] =
cd65022c6a0707f1c7112f99e9c981677fdd5518f7ddfa0f778d4cee7113e3d6
+
inherit autotools
# Ugly hack to work around undefined OE_QMAKE_PATH_EXTERNAL_HOST_BINS variable
diff --git a/meta/recipes-devtools/cmake/cmake_3.2.2.bb
b/meta/recipes-devtools/cmake/cmake_3.3.1.bb
similarity index 92%
rename from meta/recipes-devtools/cmake/cmake_3.2.2.bb
rename to meta/recipes-devtools/cmake/cmake_3.3.1.bb
index 4765f6c..2f188f0 100644
--- a/meta/recipes-devtools/cmake/cmake_3.2.2.bb
+++ b/meta/recipes-devtools/cmake/cmake_3.3.1.bb
@@ -8,9 +8,6 @@ SRC_URI_append_class-nativesdk = \
file://OEToolchainConfig.cmake \
file://environment.d-cmake.sh
-SRC_URI[md5sum] = 2da57308071ea98b10253a87d2419281
-SRC_URI[sha256sum] =
ade94e6e36038774565f2aed8866415443444fb7a362eb0ea5096e40d5407c78
-
# Strip ${prefix} from ${docdir}, set result into docdir_stripped
python () {
prefix=d.getVar(prefix, True)
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2 1/1] classes/whitelist: add class to allow whitelisting recipes from a layer
On Fri, Aug 28, 2015 at 11:00 AM, Paul Eggleton paul.eggle...@linux.intel.com wrote: On Friday 28 August 2015 10:55:41 Otavio Salvador wrote: On Fri, Aug 28, 2015 at 3:07 AM, Khem Raj raj.k...@gmail.com wrote: On Aug 27, 2015, at 5:36 AM, Paul Eggleton paul.eggle...@linux.intel.com wrote: Allow restricting recipes brought from a layer to a specified list. This is similar in operation to blacklist.bbclass, but instead specifies a per-layer whitelist of recipes (matched by PN or BPN) that are able to be built from the layer - anything else is skipped. This is potentially useful where you want to bring in a select set of recipes from a larger layer e.g. meta-oe. For the record, I am not in favor of such feature in OE, Distros can still use BBMASK if they wish to I am also not in favor of the merge of this. Do you have a practical alternative that has less downsides? I do want people using full layers and offer tools to make fancy combinations does not enhance our quality in long term. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 1/2] android-tools: import android-tools from meta-smartphone into oe-core
On Wed, Aug 26, 2015 at 12:48 PM, Nicolas Dechesne nicolas.deche...@linaro.org wrote: The following changes were done to trim down the recipe size: * removed adbd support * removed android-tools-conf The main idea is to keep only what is strictly needed for make_ext4fs tool. Signed-off-by: Nicolas Dechesne nicolas.deche...@linaro.org Can you explain Why? -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2 1/1] classes/whitelist: add class to allow whitelisting recipes from a layer
On Friday 28 August 2015 11:09:19 Otavio Salvador wrote: On Fri, Aug 28, 2015 at 11:00 AM, Paul Eggleton paul.eggle...@linux.intel.com wrote: On Friday 28 August 2015 10:55:41 Otavio Salvador wrote: On Fri, Aug 28, 2015 at 3:07 AM, Khem Raj raj.k...@gmail.com wrote: On Aug 27, 2015, at 5:36 AM, Paul Eggleton paul.eggle...@linux.intel.com wrote: Allow restricting recipes brought from a layer to a specified list. This is similar in operation to blacklist.bbclass, but instead specifies a per-layer whitelist of recipes (matched by PN or BPN) that are able to be built from the layer - anything else is skipped. This is potentially useful where you want to bring in a select set of recipes from a larger layer e.g. meta-oe. For the record, I am not in favor of such feature in OE, Distros can still use BBMASK if they wish to I am also not in favor of the merge of this. Do you have a practical alternative that has less downsides? I do want people using full layers and offer tools to make fancy combinations does not enhance our quality in long term. OK, sure - but you do appreciate that we do have an underlying problem here irrespective of whether this class gets taken into OE-Core or not, right? Look, if people are really opposed to this then fine, I withdraw it. I just hope that it's understood that this class or other equivalent methods *will* get used until we fix the problem properly - all it means is the class will get copied around instead of being in one place. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] utils/decorators.py: TestNeedsBin, decorator for sending binaries to images
TestNeedsBin is a decorator to help deploy binaries to the running image. It uses no package management system. It gets it's source binaries from the rpm built packages found under DEPLOY_DIR_RPM. As mandatory arguments, it requires only the binary name. The binary is sent by default to the DUT's /usr/bin dir, making it available in system PATH. Like this, a test should only call the desired binary name without any path. Left to do: - implement support for binaries versioning - accept any source path to a given binaries directory - add a tag - add support for exported tests that will run on remote testing env. without presence of poky related to [Yocto #7850] Signed-off-by: Costin Constantin costin.c.constan...@intel.com --- meta/lib/oeqa/utils/decorators.py | 73 +-- 1 file changed, 71 insertions(+), 2 deletions(-) diff --git a/meta/lib/oeqa/utils/decorators.py b/meta/lib/oeqa/utils/decorators.py index b9fc76c..a999018 100644 --- a/meta/lib/oeqa/utils/decorators.py +++ b/meta/lib/oeqa/utils/decorators.py @@ -6,13 +6,15 @@ # Most useful is skipUnlessPassed which can be used for # creating dependecies between two test methods. -import os +import os,re import logging import sys import unittest import threading import signal from functools import wraps +import subprocess as s + #get the result object from one of the upper frames provided that one of these upper frames is a unittest.case frame class getResults(object): @@ -185,4 +187,71 @@ def timeout(seconds): return wrapped_f else: return fn -return decorator \ No newline at end of file +return decorator + +# this part for the bin --- test binding +from difflib import SequenceMatcher as SM +def get_dest_folder(tune_features, folder_list): +features_list = tune_features.split( ) +features_list.reverse() +features_list = _.join(features_list) +match_rate = 0 +best_match = None +for folder in folder_list: +if SM(None, folder, features_list).ratio() match_rate: +match_rate = SM(None, folder, features_list).ratio() +best_match = folder +return best_match + + + +class TestNeedsBin(object): + +def __init__(self, bin_name, bin_ver=None, source_dir=None, dest_dir=/usr/bin, TAG=None): +try: +import bb +self.under_bitbake_env = True +except: +self.under_bitbake_env = False +self.bin_name = bin_name +self.bin_ver = bin_ver +self.source_dir = source_dir +self.dest_dir = dest_dir +self.TAG = TAG + +def transfer_bin(self): +from oeqa.oetest import oeRuntimeTest +if self.under_bitbake_env: +if not self.source_dir: +arch_dir = get_dest_folder(oeRuntimeTest.tc.d.getVar(TUNE_FEATURES, True), os.listdir(oeRuntimeTest.tc.d.getVar(DEPLOY_DIR_RPM, True))) +self.source_dir = os.path.join(oeRuntimeTest.tc.d.getVar(DEPLOY_DIR_RPM, True), arch_dir) +if not arch_dir: +bb.warn(cannot find source dir) +for file in os.listdir(self.source_dir): +if re.match(%s-[0-9].*rpm % self.bin_name, file): +rpm_name = file +local_binary = s.check_output(rpm -qlp %s % os.path.join(self.source_dir, rpm_name), shell=True).split(\n)[-2] +if local_binary[0] == r'/': +local_binary = local_binary[1:] +if os.path.isfile(os.path.join(self.source_dir, rpm_name)): +command = /usr/bin/rpm2cpio %s | cpio -idm % os.path.join(self.source_dir, rpm_name) +s.check_output(command, shell=True) +else: +bb.warn(Cannot find package file to extract!) +if os.path.isfile(local_binary): +(status, output) = oeRuntimeTest.tc.target.copy_to(local_binary, self.dest_dir) +else: +bb.warn(Cannot find binary file!) +if status != 0: +bb.warn(Error at copying binary!) + +else: #when decorator is on the remote machine +#this part will serve when tests are present on remote machine +pass + +def __call__(self, func): +def wrapped_f(*args): +self.transfer_bin() +return func(*args) +wrapped_f.__name__ = func.__name__ +return wrapped_f -- 2.1.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/3] dbus: merge .bb and .inc
On 28/08/15 16:23, Khem Raj wrote: On Fri, Aug 28, 2015 at 5:22 AM, Andrew Shadura andrew.shad...@collabora.co.uk wrote: can you send patch generated with -M 1 Gives me exact same patch, hmm. try -C No changes. -- Cheers, Andrew -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/3] dbus: merge .bb and .inc
On Fri, Aug 28, 2015 at 5:56 AM, Andrew Shadura andrew.shad...@collabora.co.uk wrote: Hello again, By the way, Khem, what's new about your systemd update patches? they are on test branch hopefully landing in master soon I have more patches for dbus recipe, but they depend on a newer systemd, so I don't send them in yet. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/3] dbus: merge .bb and .inc
On Fri, Aug 28, 2015 at 5:22 AM, Andrew Shadura andrew.shad...@collabora.co.uk wrote: can you send patch generated with -M 1 Gives me exact same patch, hmm. try -C -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 5/5] packagegroup-base: pull in iw as well as wireless-tools
On Thu, Aug 27, 2015 at 10:50 PM, Khem Raj raj.k...@gmail.com wrote: +VIRTUAL-RUNTIME_wireless-tools ?= iw wireless-tools” wouldn’t the define from default-providers.inc be enough ? Yeah, I guess I'm just paranoid and like to avoid the implicit dependency, but duplicating the value isn't ideal either. I'll remove the dupe when I re-submit to fix the missing Upstream-Status. Thanks. -- Christopher Larson kergoth at gmail dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gcc-source: exlude from world
On 2015-08-27 11:27 PM, Khem Raj wrote:
On Thu, Aug 27, 2015 at 8:17 PM, Randy MacLeod
randy.macl...@windriver.com wrote:
I've sent the parent email to fix
$ bitbake -c stage world.
I've confirmed that my change works for:
$ bitbake -c configure world
I wasn't sure if I should leave gcc-source as
is or change it to be similar to kernel-devsrc
because meta/recipes-devtools/gcc/gcc-source.inc does:
deltask do_configure
deltask do_compile
deltask do_package
if a task is deleted and you do -c that-task then you should get an
error. deltask would create no stamps as opposed to noop tasks. May be
it can be turned into warning ( not convinced for that too)
but excluding it world doesn't sound a good solution here.
I'd be happy to change the deltask lines to do_foo[noexec] = 1
if people agree on that. Would that work for you Khem?
The kernel-devsrc and gcc-source packages are really
a different class of recipes from -native or target and if
we had more than two of them, we should create a class to
encapsulate their behaviour and ensure that they don't
break bitbake -c stage world builds. I haven't tried that
yet but I expect the class would just have the do_foo[noexec] = 1
so you don't have to type it in each of the two recipes of this
type that we currently have! :)
I'd like to do the:
do_foo[noexec] = 1
now and figure out how to handle foo-source in 2.1. Agreed?
I'll include the [YOCTO #7878] in a v2 once I get some
guidance on what is acceptable.
../Randy
...
whereas meta/recipes-kernel/linux/kernel-devsrc.bb does:
# There's nothing to do here, except install the source where we can package
it
do_fetch[noexec] = 1
do_unpack[noexec] = 1
do_patch[noexec] = 1
...
The kernel-devsrc approach doesn't break world builds
but it's probably slightly less efficient.
Also do people care about consistency in naming:
gcc-source.inc vs
kernel-devsrc.bb
? There are only two such 'source' packages so it's not a big deal.
../Randy
On 2015-08-27 11:09 PM, Randy MacLeod wrote:
Exclude all versions of gcc-source from world builds so that:
bitbake -c stage world
will work. gcc-source deletes most bitbake build stages
since it is a source-only package.
Signed-off-by: Randy MacLeod randy.macl...@windriver.com
---
meta/recipes-devtools/gcc/gcc-source_4.8.bb | 2 ++
meta/recipes-devtools/gcc/gcc-source_4.9.bb | 2 ++
meta/recipes-devtools/gcc/gcc-source_5.2.bb | 2 ++
3 files changed, 6 insertions(+)
diff --git a/meta/recipes-devtools/gcc/gcc-source_4.8.bb
b/meta/recipes-devtools/gcc/gcc-source_4.8.bb
index 234b82e..b890fa3 100644
--- a/meta/recipes-devtools/gcc/gcc-source_4.8.bb
+++ b/meta/recipes-devtools/gcc/gcc-source_4.8.bb
@@ -1,2 +1,4 @@
require recipes-devtools/gcc/gcc-${PV}.inc
require recipes-devtools/gcc/gcc-source.inc
+
+EXCLUDE_FROM_WORLD = 1
diff --git a/meta/recipes-devtools/gcc/gcc-source_4.9.bb
b/meta/recipes-devtools/gcc/gcc-source_4.9.bb
index 234b82e..b890fa3 100644
--- a/meta/recipes-devtools/gcc/gcc-source_4.9.bb
+++ b/meta/recipes-devtools/gcc/gcc-source_4.9.bb
@@ -1,2 +1,4 @@
require recipes-devtools/gcc/gcc-${PV}.inc
require recipes-devtools/gcc/gcc-source.inc
+
+EXCLUDE_FROM_WORLD = 1
diff --git a/meta/recipes-devtools/gcc/gcc-source_5.2.bb
b/meta/recipes-devtools/gcc/gcc-source_5.2.bb
index 234b82e..b890fa3 100644
--- a/meta/recipes-devtools/gcc/gcc-source_5.2.bb
+++ b/meta/recipes-devtools/gcc/gcc-source_5.2.bb
@@ -1,2 +1,4 @@
require recipes-devtools/gcc/gcc-${PV}.inc
require recipes-devtools/gcc/gcc-source.inc
+
+EXCLUDE_FROM_WORLD = 1
--
# Randy MacLeod. SMTS, Linux, Wind River
Direct: 613.963.1350 | 350 Terry Fox Drive, Suite 200, Ottawa, ON, Canada,
K2K 2W5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
# Randy MacLeod. SMTS, Linux, Wind River
Direct: 613.963.1350 | 350 Terry Fox Drive, Suite 200, Ottawa, ON,
Canada, K2K 2W5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/8] dpkg: update to 1.18.2
On Aug 28, 2015, at 5:18 AM, Alexander Kanavin alexander.kana...@linux.intel.com wrote: check_snprintf.patch has been dropped, because it seems to fix a problem that doesn't anymore exist, and doesn't have any description of what the problem was and how was it fixed. it is redundant. should be fine signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2 1/1] classes/whitelist: add class to allow whitelisting recipes from a layer
On Aug 28, 2015, at 1:34 AM, Paul Eggleton paul.eggle...@linux.intel.com wrote: On Thursday 27 August 2015 23:07:44 Khem Raj wrote: On Aug 27, 2015, at 5:36 AM, Paul Eggleton paul.eggle...@linux.intel.com wrote: Allow restricting recipes brought from a layer to a specified list. This is similar in operation to blacklist.bbclass, but instead specifies a per-layer whitelist of recipes (matched by PN or BPN) that are able to be built from the layer - anything else is skipped. This is potentially useful where you want to bring in a select set of recipes from a larger layer e.g. meta-oe. For the record, I am not in favor of such feature in OE, Distros can still use BBMASK if they wish to This is significantly easier to use than BBMASK though. (Perhaps that's why you don't like it?) I don’t think its about technical merits of the patch. I understand its pretty well writter. Its if we want to provide more tools and ways which can be bad for layer health in general which are besides oe-core. I think we need to be realistic here as I said in my most recent reply to the other thread - people will do this using whatever mechanism is available whether we like it or not. And what are they saying by doing so? They're effectively telling us that they can't consume the recipes in the way we are currently collecting them together. We know what the proper fix for the problem is (increased splitting of large layers such as meta-oe), it may not be easy but other than workarounds like this I don't see an alternative. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 4/5] iw: support and enable separate build dir
On Fri, Aug 28, 2015 at 12:38 AM, Jussi Kukkonen jussi.kukko...@intel.com wrote: On 27 August 2015 at 21:48, Christopher Larson kerg...@gmail.com wrote: From: Christopher Larson chris_lar...@mentor.com Signed-off-by: Christopher Larson chris_lar...@mentor.com --- .../iw/iw/separate-objdir.patch| 55 ++ meta/recipes-connectivity/iw/iw_4.1.bb | 4 ++ 2 files changed, 59 insertions(+) create mode 100644 meta/recipes-connectivity/iw/iw/separate-objdir.patch diff --git a/meta/recipes-connectivity/iw/iw/separate-objdir.patch b/meta/recipes-connectivity/iw/iw/separate-objdir.patch new file mode 100644 index 000..e29e461 --- /dev/null +++ b/meta/recipes-connectivity/iw/iw/separate-objdir.patch @@ -0,0 +1,55 @@ +From 9e27fc2e1b3dc8c36ef6a502edffc3a3d84d9dd9 Mon Sep 17 00:00:00 2001 +From: Christopher Larson chris_lar...@mentor.com +Date: Wed, 26 Aug 2015 17:23:48 -0700 +Subject: [PATCH] Support separation of SRCDIR and OBJDIR + +Typical use of VPATH to locate the sources. + +Signed-off-by: Christopher Larson chris_lar...@mentor.com + Upstream-Status ? Ah, oops, thanks, will re-submit. -- Christopher Larson kergoth at gmail dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Yocto Project Status WW35
Current Dev Position: 1.9 Milestone 3 (M3) Next Deadline: M3 cut off of August 24th at noon GMT (On hold until most likely late next week) SWAT team rotation: Alejandro - Jussi https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team Key Status/Updates: * Reminder: The current version that is in development will launch with YP 2.0 in October, 2015. * We have renamed YP 1.9 M4 to YP 2.0. This will be the stabilization milestone for YP 2.0 release. * The autobuilder situation is still problematic. We are continuing to try to improve its stability. * We have passed the YP 1.9 M3 final cut off, but due to our need to get a stable build; we don't expect it to go into QA until later next week. * Since we have passed YP 1.9 M3; we are at YP 1.9 / 2.0 feature freeze. All enhancements now will be pushed YP 2.1. Key YP 1.9 Dates: YP Final - 2.0 Cut off: Sept. 28, 2015 noon GMT 1.9 M3 Release Target: Before Sept. 11 2015 (Will be late) 2.0 final Release Target: Before Oct. 30, 2015 Key Status Links for YP: https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.9_Status https://wiki.yoctoproject.org/wiki/Yocto_1.9_Schedule https://wiki.yoctoproject.org/wiki/Yocto_1.9_Features Tracking Metrics: WDD 2023 (last week 1950) (https://wiki.yoctoproject.org/charts/combo.html) [If anyone has suggestions for other information you'd like to see on this weekly status update, let us know!] Thanks, Stephen K. Jolley Yocto Project Program Manager INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124 * Work Telephone: (503) 712-0534 *Cell:(208) 244-4460 * Email: stephen.k.jol...@intel.com -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2][dizzy] license_class: fix license.manifest shows LICENSE field differently to recipe
merged to staging
thanks
armin
On 08/24/2015 10:12 AM, Aníbal Limón wrote:
Drop removal of [|()*] operators in pkged_lic because this removal is only
needed to validate if license is collected.
[YOCTO #6757]
(From OE-Core rev: 57e5f74382d51f2a8df00e18b6008e3d2b44ad1a)
Signed-off-by: Aníbal Limón anibal.li...@linux.intel.com
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
meta/classes/license.bbclass | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/meta/classes/license.bbclass b/meta/classes/license.bbclass
index 91d8bab..dfb162d 100644
--- a/meta/classes/license.bbclass
+++ b/meta/classes/license.bbclass
@@ -49,24 +49,25 @@ license_create_manifest() {
pkged_pv=$(sed -n 's/^PV: //p' ${filename})
pkged_name=$(basename $(readlink ${filename}))
- pkged_lic=$(sed -n /^LICENSE_${pkged_name}: /{
s/^LICENSE_${pkged_name}: //; s/[|()*]/ /g; s/ */ /g; p } ${filename})
+ pkged_lic=$(sed -n /^LICENSE_${pkged_name}: /{
s/^LICENSE_${pkged_name}: //; p } ${filename})
if [ -z ${pkged_lic} ]; then
# fallback checking value of LICENSE
- pkged_lic=$(sed -n /^LICENSE: /{ s/^LICENSE: //;
s/[|()*]/ /g; s/ */ /g; p } ${filename})
+ pkged_lic=$(sed -n /^LICENSE: /{ s/^LICENSE: //; p }
${filename})
fi
echo PACKAGE NAME: ${pkg} ${LICENSE_MANIFEST}
echo PACKAGE VERSION: ${pkged_pv} ${LICENSE_MANIFEST}
echo RECIPE NAME: ${pkged_pn} ${LICENSE_MANIFEST}
- printf LICENSE: ${LICENSE_MANIFEST}
- for lic in ${pkged_lic}; do
+ echo LICENSE: ${pkged_lic} ${LICENSE_MANIFEST}
+ echo ${LICENSE_MANIFEST}
+
+ lics=$(echo ${pkged_lic} | sed s/[|()*]/ /g | sed s/ */
/g )
+ for lic in ${lics}; do
# to reference a license file trim trailing + symbol
if ! [ -e
${LICENSE_DIRECTORY}/${pkged_pn}/generic_${lic%+} ]; then
bbwarn The license listed ${lic} was not in
the licenses collected for ${pkged_pn}
fi
-printf ${lic} ${LICENSE_MANIFEST}
done
- printf \n\n ${LICENSE_MANIFEST}
done
# Two options here:
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH][dizzy] qemu-slirp: CVE-2014-3640
merged to staging
thanks
- armin
On 08/25/2015 02:50 AM, Sona Sarmadi wrote:
Fixes NULL pointer deref in sosendto().
Reference:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3640
Upstream patch:
http://git.qemu.org/?p=qemu.git;a=commit;
h=9a72433843d912a45046959b1953861211d1838d
Signed-off-by: Sona Sarmadi sona.sarm...@enea.com
---
.../qemu/qemu/slirp-CVE-2014-3640.patch| 48
++
meta/recipes-devtools/qemu/qemu_2.1.0.bb | 1 +
2 files changed, 49 insertions(+)
create mode 100644 meta/recipes-devtools/qemu/qemu/slirp-CVE-2014-3640.patch
diff --git a/meta/recipes-devtools/qemu/qemu/slirp-CVE-2014-3640.patch
b/meta/recipes-devtools/qemu/qemu/slirp-CVE-2014-3640.patch
new file mode 100644
index 000..a7ecf31
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/slirp-CVE-2014-3640.patch
@@ -0,0 +1,48 @@
+From 9a72433843d912a45046959b1953861211d1838d Mon Sep 17 00:00:00 2001
+From: Petr Matousek pmato...@redhat.com
+Date: Thu, 18 Sep 2014 08:35:37 +0200
+Subject: [PATCH] slirp: udp: fix NULL pointer dereference because of
+ uninitialized socket
+
+When guest sends udp packet with source port and source addr 0,
+uninitialized socket is picked up when looking for matching and already
+created udp sockets, and later passed to sosendto() where NULL pointer
+dereference is hit during so-slirp-vnetwork_mask.s_addr access.
+
+Fix this by checking that the socket is not just a socket stub.
+
+This is CVE-2014-3640.
+
+Upstream-Status: Backport
+
+Signed-off-by: Petr Matousek pmato...@redhat.com
+Reported-by: Xavier Mehrenberger xavier.mehrenber...@airbus.com
+Reported-by: Stephane Duverger stephane.duver...@eads.net
+Reviewed-by: Jan Kiszka jan.kis...@siemens.com
+Reviewed-by: Michael S. Tsirkin m...@redhat.com
+Reviewed-by: Michael Tokarev m...@tls.msk.ru
+Message-id: 20140918063537.gx9...@dhcp-25-225.brq.redhat.com
+Signed-off-by: Peter Maydell peter.mayd...@linaro.org
+(cherry picked from commit 01f7cecf0037997cb0e58ec0d56bf9b5a6f7cb2a)
+Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com
+Signed-off-by: Sona Sarmadi sona.sarm...@enea.com
+---
+ slirp/udp.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/slirp/udp.c b/slirp/udp.c
+index 8cc6cb6..f77e00f 100644
+--- a/slirp/udp.c
b/slirp/udp.c
+@@ -152,7 +152,7 @@ udp_input(register struct mbuf *m, int iphlen)
+ * Locate pcb for datagram.
+ */
+ so = slirp-udp_last_so;
+-if (so-so_lport != uh-uh_sport ||
++if (so == slirp-udb || so-so_lport != uh-uh_sport ||
+ so-so_laddr.s_addr != ip-ip_src.s_addr) {
+ struct socket *tmp;
+
+--
+1.9.1
+
diff --git a/meta/recipes-devtools/qemu/qemu_2.1.0.bb
b/meta/recipes-devtools/qemu/qemu_2.1.0.bb
index 444a422..92a89d6 100644
--- a/meta/recipes-devtools/qemu/qemu_2.1.0.bb
+++ b/meta/recipes-devtools/qemu/qemu_2.1.0.bb
@@ -10,6 +10,7 @@ SRC_URI +=
file://configure-fix-Darwin-target-detection.patch \
file://qemu-CVE-2015-3456.patch \
file://CVE-2014-7840.patch \
file://vnc-CVE-2014-7815.patch \
+file://slirp-CVE-2014-3640.patch \
SRC_URI_prepend = http://wiki.qemu-project.org/download/${BP}.tar.bz2;
SRC_URI[md5sum] = 6726977292b448cbc7f89998fac6983b
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2 1/1] classes/whitelist: add class to allow whitelisting recipes from a layer
On Fri, Aug 28, 2015 at 11:19 AM, Paul Eggleton paul.eggle...@linux.intel.com wrote: On Friday 28 August 2015 11:09:19 Otavio Salvador wrote: On Fri, Aug 28, 2015 at 11:00 AM, Paul Eggleton paul.eggle...@linux.intel.com wrote: On Friday 28 August 2015 10:55:41 Otavio Salvador wrote: On Fri, Aug 28, 2015 at 3:07 AM, Khem Raj raj.k...@gmail.com wrote: On Aug 27, 2015, at 5:36 AM, Paul Eggleton paul.eggle...@linux.intel.com wrote: Allow restricting recipes brought from a layer to a specified list. This is similar in operation to blacklist.bbclass, but instead specifies a per-layer whitelist of recipes (matched by PN or BPN) that are able to be built from the layer - anything else is skipped. This is potentially useful where you want to bring in a select set of recipes from a larger layer e.g. meta-oe. For the record, I am not in favor of such feature in OE, Distros can still use BBMASK if they wish to I am also not in favor of the merge of this. Do you have a practical alternative that has less downsides? I do want people using full layers and offer tools to make fancy combinations does not enhance our quality in long term. OK, sure - but you do appreciate that we do have an underlying problem here irrespective of whether this class gets taken into OE-Core or not, right? Look, if people are really opposed to this then fine, I withdraw it. I just hope that it's understood that this class or other equivalent methods *will* get used until we fix the problem properly - all it means is the class will get copied around instead of being in one place. I don't think we (as OE) should help people to do bad things; people are good in inventing ways of doing bad things and we should try to provide them guidance to avoid those, not promote tools to help them in doing bad development practices. OE-Core shouldn't handle and maintain this infrastructure, in my view. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [RFC][PATCH] pulseaudio: improve PACKAGECONFIG for dbus/consolekit dependencies
* the problem is that consolekit module is built whenever dbus is enabled
and consolekit is available only in distributions with x11 in DISTRO_FEATURES
* many distributions want to enable dbus support (required for bluez support),
but without consolekit because they aren't using x11
* allow to completely disable dbus (and consolekit)
* add consolekit runtime dependency only for x11 in DISTRO_FEATURES
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
meta/recipes-multimedia/pulseaudio/pulseaudio.inc | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
index 3389ec9..a2b4446 100644
--- a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
+++ b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
@@ -9,7 +9,7 @@ LIC_FILES_CHKSUM =
file://GPL;md5=4325afd396febcb659c36b49533135d4 \
DEPENDS = libatomics-ops liboil libsndfile1 libtool
# optional
-DEPENDS += udev alsa-lib glib-2.0 dbus gconf
+DEPENDS += udev alsa-lib glib-2.0 gconf
DEPENDS += json-c gdbm speexdsp libxml-parser-perl-native libcap
inherit autotools pkgconfig useradd gettext perlnative bluetooth systemd
@@ -37,8 +37,10 @@ PACKAGECONFIG ??= ${@bb.utils.contains('DISTRO_FEATURES',
'bluetooth', '${BLUEZ
${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11', '',
d)} \
${@bb.utils.contains('DISTRO_FEATURES', '3g', 'ofono', '',
d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'systemd',
'systemd', '', d)} \
+ dbus \
+PACKAGECONFIG[dbus] = --enable-dbus,--disable-dbus,dbus
PACKAGECONFIG[bluez4] = --enable-bluez4,--disable-bluez4,bluez4 sbc
PACKAGECONFIG[bluez5] = --enable-bluez5,--disable-bluez5,bluez5 sbc
PACKAGECONFIG[ofono] =
--enable-bluez5-ofono-headset,--disable-bluez5-ofono-headset,ofono
@@ -75,7 +77,7 @@ USERADD_PARAM_pulseaudio-server = --system --home
/var/run/pulse \
# adding the console-kit module to an image, we also get the necessary
# consolekit package produced.
PACKAGES =+ libpulsecore libpulsecommon libpulse libpulse-simple
libpulse-mainloop-glib \
- pulseaudio-server pulseaudio-misc
${@bb.utils.contains('PACKAGECONFIG', 'x11', 'pulseaudio-module-console-kit',
'', d)}
+ pulseaudio-server pulseaudio-misc
${@bb.utils.contains('PACKAGECONFIG', 'dbus', 'pulseaudio-module-console-kit',
'', d)}
#upgrade path:
RREPLACES_pulseaudio-server = libpulse-bin libpulse-conf
@@ -157,7 +159,9 @@ RDEPENDS_pulseaudio-server = \
# that makes the PulseAudio plugin the default ALSA device.
RDEPENDS_pulseaudio-server += alsa-plugins-pulseaudio-conf
-RDEPENDS_pulseaudio-module-console-kit =+ consolekit
+# pulseaudio-module-console-kit is built whenever dbus is enabled by
PACKAGECONFIG
+# but consolekit depends on libx11 and is available only for DISTRO with x11
in DISTRO_FEATURES
+RDEPENDS_pulseaudio-module-console-kit =+
${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'consolekit', '', d)}
RDEPENDS_pulseaudio-misc += pulseaudio-module-cli-protocol-unix
FILES_pulseaudio-module-gconf += ${libexecdir}/pulse/gconf-helper
--
2.5.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] systemd: Increase devices timeout in QEMU machines to avoid failures on serial-getty
Systemd serial-getty is failing because dev-tty ends with timeout, systemd
uses a default timeout of 90 secs that it's reached on AB's production
environment
due to high I/O loads (nfs).
When use QEMU is used without KVM support, the machine code is executed by TCG
(software code execution) that is dependent on devices layer and causes locks
between TCG/Devices increasing the machine code execution time [1].
QEMU don't support configuration of device timeout always uses a default one
that is
90 secs, so the next patch increases the device timeout to 240 secs [2] in
order give
enough time to get devices ready. It ONLY applies on QEMU machines.
[YOCTO #8141]
[1]
http://blog.vmsplice.net/2011/03/qemu-internals-overall-architecture-and.html
[2] https://bugzilla.yoctoproject.org/show_bug.cgi?id=8141#c10
Signed-off-by: Aníbal Limón anibal.li...@linux.intel.com
---
c-Change-the-default-device-timeout-to-2.patch | 31 ++
meta/recipes-core/systemd/systemd_219.bb | 1 +
2 files changed, 32 insertions(+)
create mode 100644
meta/recipes-core/systemd/systemd/qemuall_io_latency-core-device.c-Change-the-default-device-timeout-to-2.patch
diff --git
a/meta/recipes-core/systemd/systemd/qemuall_io_latency-core-device.c-Change-the-default-device-timeout-to-2.patch
b/meta/recipes-core/systemd/systemd/qemuall_io_latency-core-device.c-Change-the-default-device-timeout-to-2.patch
new file mode 100644
index 000..c7e1711
--- /dev/null
+++
b/meta/recipes-core/systemd/systemd/qemuall_io_latency-core-device.c-Change-the-default-device-timeout-to-2.patch
@@ -0,0 +1,31 @@
+Upstream-Status: Inappropriate [Specific case QEMU/AB]
+
+From 7b8c4e0a67a79a75e1bd77df3a452a5497322108 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?An=C3=ADbal=20Lim=C3=B3n?= anibal.li...@linux.intel.com
+Date: Thu, 27 Aug 2015 17:58:26 -0500
+Subject: [PATCH] core/device.c: Change the default device timeout to 240 sec.
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Signed-off-by: Aníbal Limón anibal.li...@linux.intel.com
+---
+ src/core/device.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/core/device.c b/src/core/device.c
+index e7efcf0..4ed8f08 100644
+--- a/src/core/device.c
b/src/core/device.c
+@@ -110,7 +110,7 @@ static void device_init(Unit *u) {
+ * indefinitely for plugged in devices, something which cannot
+ * happen for the other units since their operations time out
+ * anyway. */
+-u-job_timeout = u-manager-default_timeout_start_usec;
++u-job_timeout = (240 * USEC_PER_SEC);
+
+ u-ignore_on_isolate = true;
+ u-ignore_on_snapshot = true;
+--
+1.9.1
+
diff --git a/meta/recipes-core/systemd/systemd_219.bb
b/meta/recipes-core/systemd/systemd_219.bb
index e187cea..2326753 100644
--- a/meta/recipes-core/systemd/systemd_219.bb
+++ b/meta/recipes-core/systemd/systemd_219.bb
@@ -50,6 +50,7 @@ SRC_URI =
git://github.com/systemd/systemd-stable;branch=v219-stable;protocol=g
file://init \
file://run-ptest \
+SRC_URI_append_qemuall =
file://qemuall_io_latency-core-device.c-Change-the-default-device-timeout-to-2.patch
S = ${WORKDIR}/git
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gcc-source: exlude from world
On Aug 28, 2015, at 8:45 AM, Randy MacLeod randy.macl...@windriver.com
wrote:
On 2015-08-27 11:27 PM, Khem Raj wrote:
On Thu, Aug 27, 2015 at 8:17 PM, Randy MacLeod
randy.macl...@windriver.com wrote:
I've sent the parent email to fix
$ bitbake -c stage world.
I've confirmed that my change works for:
$ bitbake -c configure world
I wasn't sure if I should leave gcc-source as
is or change it to be similar to kernel-devsrc
because meta/recipes-devtools/gcc/gcc-source.inc does:
deltask do_configure
deltask do_compile
deltask do_package
if a task is deleted and you do -c that-task then you should get an
error. deltask would create no stamps as opposed to noop tasks. May be
it can be turned into warning ( not convinced for that too)
but excluding it world doesn't sound a good solution here.
I'd be happy to change the deltask lines to do_foo[noexec] = 1
if people agree on that. Would that work for you Khem?
it should work for the toolchain bootstrapping. If it does then probably we can
live with it
The kernel-devsrc and gcc-source packages are really
a different class of recipes from -native or target and if
we had more than two of them, we should create a class to
encapsulate their behaviour and ensure that they don't
break bitbake -c stage world builds. I haven't tried that
yet but I expect the class would just have the do_foo[noexec] = 1
so you don't have to type it in each of the two recipes of this
type that we currently have! :)
I'd like to do the:
do_foo[noexec] = 1
now and figure out how to handle foo-source in 2.1. Agreed?
I'll include the [YOCTO #7878] in a v2 once I get some
guidance on what is acceptable.
../Randy
...
whereas meta/recipes-kernel/linux/kernel-devsrc.bb does:
# There's nothing to do here, except install the source where we can package
it
do_fetch[noexec] = 1
do_unpack[noexec] = 1
do_patch[noexec] = 1
...
The kernel-devsrc approach doesn't break world builds
but it's probably slightly less efficient.
Also do people care about consistency in naming:
gcc-source.inc vs
kernel-devsrc.bb
? There are only two such 'source' packages so it's not a big deal.
../Randy
On 2015-08-27 11:09 PM, Randy MacLeod wrote:
Exclude all versions of gcc-source from world builds so that:
bitbake -c stage world
will work. gcc-source deletes most bitbake build stages
since it is a source-only package.
Signed-off-by: Randy MacLeod randy.macl...@windriver.com
---
meta/recipes-devtools/gcc/gcc-source_4.8.bb | 2 ++
meta/recipes-devtools/gcc/gcc-source_4.9.bb | 2 ++
meta/recipes-devtools/gcc/gcc-source_5.2.bb | 2 ++
3 files changed, 6 insertions(+)
diff --git a/meta/recipes-devtools/gcc/gcc-source_4.8.bb
b/meta/recipes-devtools/gcc/gcc-source_4.8.bb
index 234b82e..b890fa3 100644
--- a/meta/recipes-devtools/gcc/gcc-source_4.8.bb
+++ b/meta/recipes-devtools/gcc/gcc-source_4.8.bb
@@ -1,2 +1,4 @@
require recipes-devtools/gcc/gcc-${PV}.inc
require recipes-devtools/gcc/gcc-source.inc
+
+EXCLUDE_FROM_WORLD = 1
diff --git a/meta/recipes-devtools/gcc/gcc-source_4.9.bb
b/meta/recipes-devtools/gcc/gcc-source_4.9.bb
index 234b82e..b890fa3 100644
--- a/meta/recipes-devtools/gcc/gcc-source_4.9.bb
+++ b/meta/recipes-devtools/gcc/gcc-source_4.9.bb
@@ -1,2 +1,4 @@
require recipes-devtools/gcc/gcc-${PV}.inc
require recipes-devtools/gcc/gcc-source.inc
+
+EXCLUDE_FROM_WORLD = 1
diff --git a/meta/recipes-devtools/gcc/gcc-source_5.2.bb
b/meta/recipes-devtools/gcc/gcc-source_5.2.bb
index 234b82e..b890fa3 100644
--- a/meta/recipes-devtools/gcc/gcc-source_5.2.bb
+++ b/meta/recipes-devtools/gcc/gcc-source_5.2.bb
@@ -1,2 +1,4 @@
require recipes-devtools/gcc/gcc-${PV}.inc
require recipes-devtools/gcc/gcc-source.inc
+
+EXCLUDE_FROM_WORLD = 1
--
# Randy MacLeod. SMTS, Linux, Wind River
Direct: 613.963.1350 | 350 Terry Fox Drive, Suite 200, Ottawa, ON, Canada,
K2K 2W5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
# Randy MacLeod. SMTS, Linux, Wind River
Direct: 613.963.1350 | 350 Terry Fox Drive, Suite 200, Ottawa, ON, Canada,
K2K 2W5
signature.asc
Description: Message signed with OpenPGP using GPGMail
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH V3 3/3] runqemu: Define OECORE_MACHINE_SYSROOT on setup_sysroot
On Fri, 2015-08-28 at 08:34 -0500, Leonardo Sandoval wrote: Hi Patrick, I do not have much time for a V4 set of patches, but now with all your input I can rework V3 patches on 2.1. What do you mean with rework on on 2.1? I have some other runqemu changes pending locally (support booting hddimg), so runqemu internals are still kinda fresh in my mind. If you don't have time, then I can rework the patch series. However, it's a side project for me, too. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/3] Empty-image functionality
Acked-by: Aníbal Limón anibal.li...@linux.intel.com On 26/08/15 16:57, Alex Franco wrote: Enable creation of core-empty-image (a recipe that inherits image without any extra packages) or similar empty images, whether RPM, DEB or IPK packaging is selected. [YOCTO #7664] Alex Franco (3): Empty image: core-image-empty recipe, Rootfs fix Empty image: package list splitting and iteration Empty image: filesystem allocation meta/classes/image_types.bbclass | 10 +- meta/classes/license.bbclass | 2 +- meta/lib/oe/package_manager.py | 5 +++-- meta/lib/oe/rootfs.py| 8 ++-- meta/recipes-core/images/core-image-empty.bb | 7 +++ 5 files changed, 26 insertions(+), 6 deletions(-) create mode 100644 meta/recipes-core/images/core-image-empty.bb -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-commits] Armin Kuster : tzdata: update to 2015f
On Fri, Aug 14, 2015 at 07:31:22AM +, g...@git.openembedded.org wrote:
Module: openembedded-core.git
Branch: master
Commit: 4e0fb630d3bb0250ece6e2071ae49b2601ae3e57
URL:
http://git.openembedded.org/?p=openembedded-core.gita=commit;h=4e0fb630d3bb0250ece6e2071ae49b2601ae3e57
Author: Armin Kuster akuster...@gmail.com
Date: Tue Aug 11 11:29:04 2015 +0530
tzdata: update to 2015f
Changes affecting future time stamps
North Korea switches to +0830 on 2015-08-15. (Thanks to Steffen Thorsen.)
The abbreviation remains KST. (Thanks to Robert Elz.)
Uruguay no longer observes DST. (Thanks to Steffen Thorsen
and Pablo Camargo.)
Changes affecting past and future time stamps
Moldova starts and ends DST at 00:00 UTC, not at 01:00 UTC.
(Thanks to Roman Tudos.)
Signed-off-by: Armin Kuster akuster...@gmail.com
Signed-off-by: Ross Burton ross.bur...@intel.com
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
meta/recipes-extended/tzdata/{tzdata_2015e.bb = tzdata_2015f.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Hi Armin,
Is it intentional that upgrades like this usually remove old version,
e.g. 2015d upgrade in master:
http://git.openembedded.org/openembedded-core/commit/?id=b9f366ab4e0a9cad69b631f402b9afa02d40f667
but the same upgrade in dizzy:
http://git.openembedded.org/openembedded-core/commit/?h=dizzyid=ff1547cccd840068500193d4aec772988a1f2023
kept older 2015b version, which cause me issues, because we had
2015b.bbappend I've forgot to rename to 2015d.bbappend and bitbake
didn't complain, because 2015b was still there.
What's even worse, this upgrade to 2015d is still missing in fido
branch:
http://git.openembedded.org/openembedded-core/log/?h=fidoqt=grepq=tzdata
http://git.openembedded.org/openembedded-core/tree/meta/recipes-extended/tzdata/?h=master
tzdata_2015f.bb
http://git.openembedded.org/openembedded-core/tree/meta/recipes-extended/tzdata/?h=fido
tzdata_2015b.bb
http://git.openembedded.org/openembedded-core/tree/meta/recipes-extended/tzdata/?h=dizzy
tzdata_2014h.bb
tzdata_2015b.bb
tzdata_2015d.bb
diff --git a/meta/recipes-extended/tzdata/tzdata_2015e.bb
b/meta/recipes-extended/tzdata/tzdata_2015f.bb
similarity index 98%
rename from meta/recipes-extended/tzdata/tzdata_2015e.bb
rename to meta/recipes-extended/tzdata/tzdata_2015f.bb
index 92389a9..7cda40d 100644
--- a/meta/recipes-extended/tzdata/tzdata_2015e.bb
+++ b/meta/recipes-extended/tzdata/tzdata_2015f.bb
@@ -7,8 +7,8 @@ DEPENDS = tzcode-native
SRC_URI = ftp://ftp.iana.org/tz/releases/tzdata${PV}.tar.gz;name=tzdata;
-SRC_URI[tzdata.md5sum] = 36f9056efb432ca945c73397acfce0d4
-SRC_URI[tzdata.sha256sum] =
ffc9b5d38abda8277aa479e3f75aa7668819d0977cd1a0c8ef3b09128334ba6f
+SRC_URI[tzdata.md5sum] = e3b82732d20e973e48af1c6f13df9a1d
+SRC_URI[tzdata.sha256sum] =
959f81b541e042ecb13c50097d264ae92ff03a57979c478dbcf24d5da242531d
inherit allarch
--
___
Openembedded-commits mailing list
openembedded-comm...@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-commits
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] oeqa/runtime/multilib: fix and improve multilib test
Replace the previous shell magic with a Python function to parse the readelf
output, and fix the package names to include the lib32- prefix.
[ YOCTO #8219 ]
Signed-off-by: Ross Burton ross.bur...@intel.com
---
meta/lib/oeqa/runtime/multilib.py | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/meta/lib/oeqa/runtime/multilib.py
b/meta/lib/oeqa/runtime/multilib.py
index ab0a6cc..1c1729b 100644
--- a/meta/lib/oeqa/runtime/multilib.py
+++ b/meta/lib/oeqa/runtime/multilib.py
@@ -10,9 +10,22 @@ def setUpModule():
class MultilibTest(oeRuntimeTest):
+def parse(self, s):
+
+Parse the output of readelf -h and return the binary class, or fail.
+
+l = [l.split()[1] for l in s.split('\n') if Class: in l]
+if l:
+return l[0]
+else:
+self.fail(Cannot parse readelf output\n + s)
+
@testcase('279')
@skipUnlessPassed('test_ssh')
def test_file_connman(self):
-self.assertTrue(oeRuntimeTest.hasPackage('connman-gnome'), msg=This
test assumes connman-gnome is installed)
-(status, output) = self.target.run(readelf -h /usr/bin/connman-applet
| sed -n '3p' | awk '{print $2}')
-self.assertEqual(output, ELF32, msg=connman-applet isn't an ELF32
binary. readelf says: %s % self.target.run(readelf -h
/usr/bin/connman-applet)[1])
+self.assertTrue(oeRuntimeTest.hasPackage('lib32-connman-gnome'),
msg=This test assumes lib32-connman-gnome is installed)
+
+(status, output) = self.target.run(readelf -h
/usr/bin/connman-applet)
+self.assertEqual(status, 0, Failed to readelf
/usr/bin/connman-applet)
+theclass = self.parse(output)
+self.assertEqual(theclass, ELF32, msg=connman-applet isn't ELF32
(is %s) % theclass)
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] oeqa/runtime/multilib: change test case to use glib-2.0-utils
Using connman-applet as a multilib test case seems quite heavy due to the
numerous dependencies it has, whereas the same test (do binaries get swapped
correctly) can be done with a lower-level library containing binaries, for
example glib-2.0.
Signed-off-by: Ross Burton ross.bur...@intel.com
---
meta/lib/oeqa/runtime/multilib.py | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/meta/lib/oeqa/runtime/multilib.py
b/meta/lib/oeqa/runtime/multilib.py
index e1bcc42..59ae86d 100644
--- a/meta/lib/oeqa/runtime/multilib.py
+++ b/meta/lib/oeqa/runtime/multilib.py
@@ -39,10 +39,10 @@ class MultilibTest(oeRuntimeTest):
@testcase('279')
@skipUnlessPassed('test_check_multilib_libc')
-def test_file_connman(self):
-self.assertTrue(oeRuntimeTest.hasPackage('lib32-connman-gnome'),
msg=This test assumes lib32-connman-gnome is installed)
+def test_file_glib(self):
+self.assertTrue(oeRuntimeTest.hasPackage('lib32-libglib-2.0-utils'),
msg=This test assumes lib32-libglib-2.0-utils is installed)
-(status, output) = self.target.run(readelf -h
/usr/bin/connman-applet)
-self.assertEqual(status, 0, Failed to readelf
/usr/bin/connman-applet)
+(status, output) = self.target.run(readelf -h
/usr/bin/glib-genmarshal)
+self.assertEqual(status, 0, Failed to readelf
/usr/bin/glib-genmarshal)
theclass = self.parse(output)
-self.assertEqual(theclass, ELF32, msg=connman-applet isn't ELF32
(is %s) % theclass)
+self.assertEqual(theclass, ELF32, msg=glib-genmarshal isn't ELF32
(is %s) % theclass)
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] oeqa/runtime/multilib: add test for libc
Add a basic test to verify that /lib/libc.so.6 and /lib32/libc.so.6 have the
right ELF class.
Signed-off-by: Ross Burton ross.bur...@intel.com
---
meta/lib/oeqa/runtime/multilib.py | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/meta/lib/oeqa/runtime/multilib.py
b/meta/lib/oeqa/runtime/multilib.py
index 1c1729b..e1bcc42 100644
--- a/meta/lib/oeqa/runtime/multilib.py
+++ b/meta/lib/oeqa/runtime/multilib.py
@@ -20,8 +20,25 @@ class MultilibTest(oeRuntimeTest):
else:
self.fail(Cannot parse readelf output\n + s)
-@testcase('279')
@skipUnlessPassed('test_ssh')
+def test_check_multilib_libc(self):
+
+Check that a multilib image has both 32-bit and 64-bit libc in.
+
+
+(status, output) = self.target.run(readelf -h /lib/libc.so.6)
+self.assertEqual(status, 0, Failed to readelf /lib/libc.so.6)
+class32 = self.parse(output)
+
+(status, output) = self.target.run(readelf -h /lib64/libc.so.6)
+self.assertEqual(status, 0, Failed to readelf /lib64/libc.so.6)
+class64 = self.parse(output)
+
+self.assertEqual(class32, ELF32, msg=/lib/libc.so.6 isn't ELF32 (is
%s) % class32)
+self.assertEqual(class64, ELF64, msg=/lib64/libc.so.6 isn't ELF64
(is %s) % class64)
+
+@testcase('279')
+@skipUnlessPassed('test_check_multilib_libc')
def test_file_connman(self):
self.assertTrue(oeRuntimeTest.hasPackage('lib32-connman-gnome'),
msg=This test assumes lib32-connman-gnome is installed)
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] oeqa/runtime/multilib: change test case to use glib-2.0-utils
On 29 August 2015 at 00:43, Ross Burton ross.bur...@intel.com wrote: Using connman-applet as a multilib test case seems quite heavy due to the numerous dependencies it has, whereas the same test (do binaries get swapped correctly) can be done with a lower-level library containing binaries, for example glib-2.0. Updating the related bug made me realise that this would mean adding logic to the autobuilder to handle new and old tests, so it really isn't worth it. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] Fix mode +st on TMPDIR when creating it
A sanity check fails when TMPDIR has setuid, setgid set. It was proposed to fix this on TMPDIR creation instead of failing with a sanity test only. This patch handles removal of those special bits (and additonally, the sticky bit) from BUILDDIR and TMPDIR when these directories are created. [YOCTO #7669] Signed-off-by: Alex Franco alejandro.fra...@linux.intel.com --- meta/classes/sanity.bbclass | 5 + scripts/oe-setup-builddir | 1 + 2 files changed, 6 insertions(+) diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass index ef90fc8..2864318 100644 --- a/meta/classes/sanity.bbclass +++ b/meta/classes/sanity.bbclass @@ -686,6 +686,7 @@ def check_sanity_version_change(status, d): status.addresult(check_not_nfs(tmpdir, TMPDIR)) def check_sanity_everybuild(status, d): +import os, stat # Sanity tests which test the users environment so need to run at each build (or are so cheap # it makes sense to always run them. @@ -839,6 +840,10 @@ def check_sanity_everybuild(status, d): status.addresult(Error, TMPDIR has changed location. You need to either move it back to %s or rebuild\n % saved_tmpdir) else: bb.utils.mkdirhier(tmpdir) +# Remove setuid, setgid and sticky bits from TMPDIR +os.chmod(tmpdir, os.stat(tmpdir).st_mode ~ stat.S_ISUID) +os.chmod(tmpdir, os.stat(tmpdir).st_mode ~ stat.S_ISGID) +os.chmod(tmpdir, os.stat(tmpdir).st_mode ~ stat.S_ISVTX) with open(checkfile, w) as f: f.write(tmpdir) diff --git a/scripts/oe-setup-builddir b/scripts/oe-setup-builddir index add0b50..f5b7e4e 100755 --- a/scripts/oe-setup-builddir +++ b/scripts/oe-setup-builddir @@ -24,6 +24,7 @@ if [ -z $BUILDDIR ]; then fi mkdir -p $BUILDDIR/conf +chmod -R -st $BUILDDIR if [ ! -d $BUILDDIR ]; then echo 2 Error: The builddir ($BUILDDIR) does not exist! -- 2.5.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [fido] Please backport commit
Hello Joshua, please backport the Yocto master commit (cherry-pick) 625e0ec8b5e5f1c39b3bfad0e6adfecaf957d689 :glibc: Consider adding -Wno-error in cases when not using -O2 to Fido. This is needed in order to fix the Fido bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=8214. Thanks Juro Bystricky -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] qemu-native: Enable temporary debug info as default.
We recently enable backtrace print rev[1] for address
qemu_cpu_kick_thread() issue but without debug information
isn't useful.
[YOCTO #8143]
[1] 73a876e4ff04ebbbcd3bde62efe02146ab601e25
Signed-off-by: Aníbal Limón anibal.li...@linux.intel.com
---
meta/recipes-devtools/qemu/qemu.inc | 3 +++
1 file changed, 3 insertions(+)
diff --git a/meta/recipes-devtools/qemu/qemu.inc
b/meta/recipes-devtools/qemu/qemu.inc
index 8c1e779..d7457f2 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -30,6 +30,9 @@ SRC_URI_append_class-native = \
EXTRA_OECONF += --target-list=${@get_qemu_target_list(d)} --disable-werror
--disable-bluez --disable-libiscsi --with-system-pixman
--extra-cflags='${CFLAGS}'
+EXTRA_OECONF_append_class-native = --enable-debug --enable-debug-info
+INHIBIT_SYSROOT_STRIP = 1
+
EXTRA_OECONF_class-nativesdk = --target-list=${@get_qemu_target_list(d)}
--disable-werror \
export LIBTOOL=${HOST_SYS}-libtool
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCHv2 1/5] iw: add recipe from meta-networking
From: Christopher Larson chris_lar...@mentor.com
iw uses cfg80211/nl80211, which is the way of the future. wireless-tools uses
WEXT, which uses ioctl, which is in deep maintenance mode. See
http://wireless.kernel.org/en/developers/Documentation/Wireless-Extensions.
Also https://wireless.wiki.kernel.org/en/users/Documentation/iw indicates The
old tool iwconfing, which uses Wireless Extensions interface, is deprecated
and it's strongly recommended to switch to iw and nl80211.
Signed-off-by: Christopher Larson chris_lar...@mentor.com
---
sh-don-t-use-git-describe-for-versioning.patch | 43 ++
meta/recipes-connectivity/iw/iw_4.1.bb | 23
2 files changed, 66 insertions(+)
create mode 100644
meta/recipes-connectivity/iw/iw/0001-iw-version.sh-don-t-use-git-describe-for-versioning.patch
create mode 100644 meta/recipes-connectivity/iw/iw_4.1.bb
diff --git
a/meta/recipes-connectivity/iw/iw/0001-iw-version.sh-don-t-use-git-describe-for-versioning.patch
b/meta/recipes-connectivity/iw/iw/0001-iw-version.sh-don-t-use-git-describe-for-versioning.patch
new file mode 100644
index 000..e64dd0a
--- /dev/null
+++
b/meta/recipes-connectivity/iw/iw/0001-iw-version.sh-don-t-use-git-describe-for-versioning.patch
@@ -0,0 +1,43 @@
+From 5310abba864cfe3a8b65af130729447604190b29 Mon Sep 17 00:00:00 2001
+From: Koen Kooi k...@dominion.thruhere.net
+Date: Tue, 29 Nov 2011 17:03:27 +0100
+Subject: [PATCH] iw: version.sh: don't use git describe for versioning
+
+It will detect top-level git repositories like the Angstrom setup-scripts and
break.
+
+Upstream-Status: Unknown
+
+Signed-off-by: Koen Kooi k...@dominion.thruhere.net
+---
+ version.sh | 16 +---
+ 1 file changed, 1 insertion(+), 15 deletions(-)
+
+diff --git a/version.sh b/version.sh
+index 11d124b..5d423c4 100755
+--- a/version.sh
b/version.sh
+@@ -3,21 +3,7 @@
+ VERSION=3.15
+ OUT=$1
+
+-if [ -d .git ] head=`git rev-parse --verify HEAD 2/dev/null`; then
+- git update-index --refresh --unmerged /dev/null
+- descr=$(git describe)
+-
+- # on git builds check that the version number above
+- # is correct...
+- [ ${descr%%-*} = v$VERSION ] || exit 2
+-
+- v=${descr#v}
+- if git diff-index --name-only HEAD | read dummy ; then
+- v=$v-dirty
+- fi
+-else
+- v=$VERSION
+-fi
++v=$VERSION
+
+ echo '#include iw.h' $OUT
+ echo const char iw_version[] = \$v\; $OUT
+--
+1.7.7.3
diff --git a/meta/recipes-connectivity/iw/iw_4.1.bb
b/meta/recipes-connectivity/iw/iw_4.1.bb
new file mode 100644
index 000..e1e7c12e
--- /dev/null
+++ b/meta/recipes-connectivity/iw/iw_4.1.bb
@@ -0,0 +1,23 @@
+SUMMARY = nl80211 based CLI configuration utility for wireless devices
+DESCRIPTION = iw is a new nl80211 based CLI configuration utility for \
+wireless devices. It supports almost all new drivers that have been added \
+to the kernel recently.
+HOMEPAGE = http://wireless.kernel.org/en/users/Documentation/iw;
+SECTION = base
+LICENSE = BSD
+LIC_FILES_CHKSUM = file://COPYING;md5=878618a5c4af25e9b93ef0be1a93f774
+
+DEPENDS = libnl pkgconfig
+
+SRC_URI = http://www.kernel.org/pub/software/network/iw/${BP}.tar.gz \
+
file://0001-iw-version.sh-don-t-use-git-describe-for-versioning.patch \
+
+
+SRC_URI[md5sum] = 68c282285c71c956069957e9ca10a6a7
+SRC_URI[sha256sum] =
14bfc627b37f7f607e4ffa63a70ded15fa2ea85177f703cb17d7fe36f9c8f33d
+
+EXTRA_OEMAKE =
+
+do_install() {
+oe_runmake DESTDIR=${D} install
+}
--
2.2.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCHv2 2/5] iw: inherit pkgconfig
From: Christopher Larson chris_lar...@mentor.com
We want the dep on pkgconfig-native, not pkgconfig, and the convention is to
inherit pkgconfig when running pkg-config at build time.
Signed-off-by: Christopher Larson chris_lar...@mentor.com
---
meta/recipes-connectivity/iw/iw_4.1.bb | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-connectivity/iw/iw_4.1.bb
b/meta/recipes-connectivity/iw/iw_4.1.bb
index e1e7c12e..556af2b 100644
--- a/meta/recipes-connectivity/iw/iw_4.1.bb
+++ b/meta/recipes-connectivity/iw/iw_4.1.bb
@@ -7,7 +7,7 @@ SECTION = base
LICENSE = BSD
LIC_FILES_CHKSUM = file://COPYING;md5=878618a5c4af25e9b93ef0be1a93f774
-DEPENDS = libnl pkgconfig
+DEPENDS = libnl
SRC_URI = http://www.kernel.org/pub/software/network/iw/${BP}.tar.gz \
file://0001-iw-version.sh-don-t-use-git-describe-for-versioning.patch \
@@ -16,6 +16,8 @@ SRC_URI =
http://www.kernel.org/pub/software/network/iw/${BP}.tar.gz \
SRC_URI[md5sum] = 68c282285c71c956069957e9ca10a6a7
SRC_URI[sha256sum] =
14bfc627b37f7f607e4ffa63a70ded15fa2ea85177f703cb17d7fe36f9c8f33d
+inherit pkgconfig
+
EXTRA_OEMAKE =
do_install() {
--
2.2.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCHv2 4/5] iw: support and enable separate build dir
From: Christopher Larson chris_lar...@mentor.com
Signed-off-by: Christopher Larson chris_lar...@mentor.com
---
.../iw/iw/separate-objdir.patch| 57 ++
meta/recipes-connectivity/iw/iw_4.1.bb | 4 ++
2 files changed, 61 insertions(+)
create mode 100644 meta/recipes-connectivity/iw/iw/separate-objdir.patch
diff --git a/meta/recipes-connectivity/iw/iw/separate-objdir.patch
b/meta/recipes-connectivity/iw/iw/separate-objdir.patch
new file mode 100644
index 000..883f8b2
--- /dev/null
+++ b/meta/recipes-connectivity/iw/iw/separate-objdir.patch
@@ -0,0 +1,57 @@
+From 9e27fc2e1b3dc8c36ef6a502edffc3a3d84d9dd9 Mon Sep 17 00:00:00 2001
+From: Christopher Larson chris_lar...@mentor.com
+Date: Wed, 26 Aug 2015 17:23:48 -0700
+Subject: [PATCH] Support separation of SRCDIR and OBJDIR
+
+Typical use of VPATH to locate the sources.
+
+Upstream-Status: Pending
+
+Signed-off-by: Christopher Larson chris_lar...@mentor.com
+
+---
+ Makefile | 7 +--
+ version.sh | 2 +-
+ 2 files changed, 6 insertions(+), 3 deletions(-)
+
+diff --git a/Makefile b/Makefile
+index 548591a..da8d33a 100644
+--- a/Makefile
b/Makefile
+@@ -1,5 +1,8 @@
+ MAKEFLAGS += --no-print-directory
+
++SRCDIR ?= $(dir $(lastword $(MAKEFILE_LIST)))
++OBJDIR ?= $(PWD)
++VPATH = $(SRCDIR)
+ PREFIX ?= /usr
+ SBINDIR ?= $(PREFIX)/sbin
+ MANDIR ?= $(PREFIX)/share/man
+@@ -95,11 +98,11 @@ VERSION_OBJS := $(filter-out version.o, $(OBJS))
+ version.c: version.sh $(patsubst %.o,%.c,$(VERSION_OBJS)) nl80211.h iw.h
Makefile \
+ $(wildcard .git/index .git/refs/tags)
+ @$(NQ) ' GEN ' $@
+- $(Q)./version.sh $@
++ $(Q)cd $(SRCDIR) ./version.sh $(OBJDIR)/$@
+
+ %.o: %.c iw.h nl80211.h
+ @$(NQ) ' CC ' $@
+- $(Q)$(CC) $(CFLAGS) -c -o $@ $
++ $(Q)$(CC) -I$(SRCDIR) $(CFLAGS) -c -o $@ $
+
+ ifeq ($(IW_ANDROID_BUILD),)
+ iw: $(OBJS)
+diff --git a/version.sh b/version.sh
+index 5354383..fa954cf 100755
+--- a/version.sh
b/version.sh
+@@ -5,5 +5,5 @@ OUT=$1
+
+ v=$VERSION
+
+-echo '#include iw.h' $OUT
++echo '#include iw.h' $OUT
+ echo const char iw_version[] = \$v\; $OUT
+--
+2.2.1
+
diff --git a/meta/recipes-connectivity/iw/iw_4.1.bb
b/meta/recipes-connectivity/iw/iw_4.1.bb
index 8e27862..fafb0e3 100644
--- a/meta/recipes-connectivity/iw/iw_4.1.bb
+++ b/meta/recipes-connectivity/iw/iw_4.1.bb
@@ -11,6 +11,7 @@ DEPENDS = libnl
SRC_URI = http://www.kernel.org/pub/software/network/iw/${BP}.tar.gz \
file://0001-iw-version.sh-don-t-use-git-describe-for-versioning.patch \
+ file://separate-objdir.patch \
SRC_URI[md5sum] = 68c282285c71c956069957e9ca10a6a7
@@ -19,10 +20,13 @@ SRC_URI[sha256sum] =
14bfc627b37f7f607e4ffa63a70ded15fa2ea85177f703cb17d7fe36f9
inherit pkgconfig
EXTRA_OEMAKE = \
+-f '${S}/Makefile' \
+\
'PREFIX=${prefix}' \
'SBINDIR=${sbindir}' \
'MANDIR=${mandir}' \
+B = ${WORKDIR}/build
do_install() {
oe_runmake 'DESTDIR=${D}' install
--
2.2.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCHv2 5/5] packagegroup-base: pull in iw as well as wireless-tools
From: Christopher Larson chris_lar...@mentor.com
As was discussed in the commit which adds iw:
iw uses cfg80211/nl80211, which is the way of the future. wireless-tools uses
WEXT, which uses ioctl, which is in deep maintenance mode. See
http://wireless.kernel.org/en/developers/Documentation/Wireless-Extensions.
Also https://wireless.wiki.kernel.org/en/users/Documentation/iw indicates The
old tool iwconfing, which uses Wireless Extensions interface, is deprecated
and it's strongly recommended to switch to iw and nl80211.
wireless-tools is kept as well for now for compatibility reasons, until we
have verified that all the network configuration mechanisms are using iw.
This adds VIRTUAL-RUNTIME_wireless-tools as a distro convenience.
Signed-off-by: Christopher Larson chris_lar...@mentor.com
---
meta/conf/distro/include/default-providers.inc | 1 +
meta/recipes-core/packagegroups/packagegroup-base.bb | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/conf/distro/include/default-providers.inc
b/meta/conf/distro/include/default-providers.inc
index 8d92c2e..9f84d5c 100644
--- a/meta/conf/distro/include/default-providers.inc
+++ b/meta/conf/distro/include/default-providers.inc
@@ -22,6 +22,7 @@ VIRTUAL-RUNTIME_update-alternatives ?=
update-alternatives-opkg
VIRTUAL-RUNTIME_apm ?= apm
VIRTUAL-RUNTIME_alsa-state ?= alsa-state
VIRTUAL-RUNTIME_getopt ?= util-linux-getopt
+VIRTUAL-RUNTIME_wireless-tools ?= iw wireless-tools
#
# Default recipe providers
diff --git a/meta/recipes-core/packagegroups/packagegroup-base.bb
b/meta/recipes-core/packagegroups/packagegroup-base.bb
index 262d65f..9e40b28 100644
--- a/meta/recipes-core/packagegroups/packagegroup-base.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-base.bb
@@ -292,7 +292,7 @@ RRECOMMENDS_packagegroup-base-ipsec = \
#
SUMMARY_packagegroup-base-wifi = WiFi support
RDEPENDS_packagegroup-base-wifi = \
-wireless-tools \
+${VIRTUAL-RUNTIME_wireless-tools} \
${@bb.utils.contains('COMBINED_FEATURES', 'pcmcia', 'hostap-utils', '',d)}
\
${@bb.utils.contains('COMBINED_FEATURES', 'pci', 'hostap-utils', '',d)} \
wpa-supplicant
--
2.2.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCHv2 0/5] Add 'iw' recipe and include in packagegroup-base
From: Christopher Larson chris_lar...@mentor.com iw uses cfg80211/nl80211, which is the way of the future. wireless-tools uses WEXT, which uses ioctl, which is in deep maintenance mode. See http://wireless.kernel.org/en/developers/Documentation/Wireless-Extensions. Also https://wireless.wiki.kernel.org/en/users/Documentation/iw indicates The old tool iwconfing, which uses Wireless Extensions interface, is deprecated and it's strongly recommended to switch to iw and nl80211. See also the mailing list thread '[OE-core] iw in place of wireless-tools'. v2 changes: add Upstream-Status to patch, remove duplicate VIRTUAL-RUNTIME_wireless-tools definition. The following changes since commit f07045fcae859c902434062d1725f1348f42d1dd: oeqa/oetest.py: add better package search for hasPackage() (2015-08-26 08:26:37 +0100) are available in the git repository at: git://github.com/kergoth/openembedded-core add-iw https://github.com/kergoth/openembedded-core/tree/add-iw Christopher Larson (5): iw: add recipe from meta-networking iw: inherit pkgconfig iw: obey our target path variables iw: support and enable separate build dir packagegroup-base: pull in iw as well as wireless-tools meta/conf/distro/include/default-providers.inc | 1 + sh-don-t-use-git-describe-for-versioning.patch | 43 .../iw/iw/separate-objdir.patch| 57 ++ meta/recipes-connectivity/iw/iw_4.1.bb | 33 + .../packagegroups/packagegroup-base.bb | 2 +- 5 files changed, 135 insertions(+), 1 deletion(-) create mode 100644 meta/recipes-connectivity/iw/iw/0001-iw-version.sh-don-t-use-git-describe-for-versioning.patch create mode 100644 meta/recipes-connectivity/iw/iw/separate-objdir.patch create mode 100644 meta/recipes-connectivity/iw/iw_4.1.bb -- 2.2.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCHv2 3/5] iw: obey our target path variables
From: Christopher Larson chris_lar...@mentor.com
Signed-off-by: Christopher Larson chris_lar...@mentor.com
---
meta/recipes-connectivity/iw/iw_4.1.bb | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-connectivity/iw/iw_4.1.bb
b/meta/recipes-connectivity/iw/iw_4.1.bb
index 556af2b..8e27862 100644
--- a/meta/recipes-connectivity/iw/iw_4.1.bb
+++ b/meta/recipes-connectivity/iw/iw_4.1.bb
@@ -18,8 +18,12 @@ SRC_URI[sha256sum] =
14bfc627b37f7f607e4ffa63a70ded15fa2ea85177f703cb17d7fe36f9
inherit pkgconfig
-EXTRA_OEMAKE =
+EXTRA_OEMAKE = \
+'PREFIX=${prefix}' \
+'SBINDIR=${sbindir}' \
+'MANDIR=${mandir}' \
+
do_install() {
-oe_runmake DESTDIR=${D} install
+oe_runmake 'DESTDIR=${D}' install
}
--
2.2.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC PATCH 1/2] android-tools: import android-tools from meta-smartphone into oe-core
On 26 August 2015 at 16:48, Nicolas Dechesne nicolas.deche...@linaro.org wrote: The main idea is to keep only what is strictly needed for make_ext4fs tool. Assuming that make_ext4fs is a tool to create an ext4 file system, what's the difference between that and our mke2fs which is used to create ext4 file systems? Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 00/17] For Dizzy 1.7.3a
Please consider these addition changes for Dizzy 1.7.3 The following changes since commit 86971b5d97645cdbf2e48c39f30afa7c44e81e81: oeqa/bbtests: Fix to ensure DL_DIR is set (2015-07-26 07:59:00 +) are available in the git repository at: git://git.yoctoproject.org/poky-contrib akuster/dizzy-next http://git.yoctoproject.org/cgit.cgi//log/?h=akuster/dizzy-next Alejandro Hernandez (1): qemurunner: Improves checking for server and target IPs on qemus parameters Aníbal Limón (2): license_class: Fix choose_lic_set into incompatible license license_class: fix license.manifest shows LICENSE field differently to recipe Martin Jansa (2): connman-conf: fix SRC_URI_append license.bbclass: fix unexpected operator for LICENSE values with space Paul Eggleton (1): oeqa/utils/qemurunner: fix logging Petter Mabäcker (1): meta: set proper S value Richard Purdie (3): dpkg: Fix for Fedora22 and new versions of tar dpkg: Fix tarfix.patch grub-efi: Add backslash lost from previous commit Ross Burton (1): oeqa/QemuRunner: don't use bb for logging Saul Wold (1): grub-efi: Use the backport patch from grub Sona Sarmadi (4): bind9.9.5: CVE-2015-5477 qemu: CVE-2014-7840 qemu-vnc: CVE-2014-7815 qemu-slirp: CVE-2014-3640 Yi Zhao (1): oeqa/selftest: fix test_incremental_image_generation for changes in log output meta/classes/license.bbclass | 18 +++--- meta/lib/oeqa/selftest/buildoptions.py | 11 ++-- meta/lib/oeqa/utils/qemurunner.py | 73 -- meta/recipes-bsp/alsa-state/alsa-state.bb | 2 + meta/recipes-bsp/grub/grub-efi_2.00.bb | 1 + meta/recipes-bsp/hostap/hostap-conf_1.0.bb | 2 + meta/recipes-bsp/keymaps/keymaps_1.0.bb| 2 + .../bind/bind/bind9_9_5-CVE-2015-5477.patch| 45 + meta/recipes-connectivity/bind/bind_9.9.5.bb | 1 + meta/recipes-connectivity/connman/connman-conf.bb | 8 ++- .../ppp-dialin/ppp-dialin_0.1.bb | 2 + .../init-ifupdown/init-ifupdown_1.0.bb | 2 + .../initrdscripts/initramfs-boot_1.0.bb| 2 + .../initrdscripts/initramfs-framework_1.0.bb | 2 + .../initrdscripts/initramfs-live-boot_1.0.bb | 2 + .../initramfs-live-install-efi-testfs_1.0.bb | 2 + .../initramfs-live-install-efi_1.0.bb | 2 + .../initramfs-live-install-testfs_1.0.bb | 2 + .../initrdscripts/initramfs-live-install_1.0.bb| 2 + meta/recipes-core/initscripts/initscripts_1.0.bb | 2 + .../systemd/systemd-systemctl-native.bb| 2 + .../sysvinit/sysvinit-inittab_2.88dsf.bb | 2 +- meta/recipes-core/udev/udev-extraconf_1.1.bb | 2 + meta/recipes-devtools/dpkg/dpkg/tarfix.patch | 45 + meta/recipes-devtools/dpkg/dpkg_1.17.4.bb | 1 + meta/recipes-devtools/opkg/opkg-collateral.bb | 2 + .../recipes-devtools/qemu/qemu/CVE-2014-7840.patch | 57 + .../qemu/qemu/slirp-CVE-2014-3640.patch| 48 ++ .../qemu/qemu/vnc-CVE-2014-7815.patch | 53 meta/recipes-devtools/qemu/qemu_2.1.0.bb | 3 + .../run-postinsts/run-postinsts_1.0.bb | 2 + .../shadow/shadow-securetty_4.2.1.bb | 2 + .../xorg-xserver/xserver-xf86-config_0.1.bb| 2 + .../modutils-initscripts/modutils-initscripts.bb | 3 + meta/recipes-qt/qt-demo/qt-demo-init_0.1.bb| 2 + .../ptest-runner/ptest-runner_1.0.bb | 2 + 36 files changed, 361 insertions(+), 50 deletions(-) create mode 100644 meta/recipes-connectivity/bind/bind/bind9_9_5-CVE-2015-5477.patch create mode 100644 meta/recipes-devtools/dpkg/dpkg/tarfix.patch create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2014-7840.patch create mode 100644 meta/recipes-devtools/qemu/qemu/slirp-CVE-2014-3640.patch create mode 100644 meta/recipes-devtools/qemu/qemu/vnc-CVE-2014-7815.patch -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 00/17] For Dizzy 1.7.3a
On Fri, Aug 28, 2015 at 12:16:04PM -0700, Armin Kuster wrote: Please consider these addition changes for Dizzy 1.7.3 The following changes since commit 86971b5d97645cdbf2e48c39f30afa7c44e81e81: oeqa/bbtests: Fix to ensure DL_DIR is set (2015-07-26 07:59:00 +) Some of these changes were already applied in dizzy, you should refresh your dizzy branch: OE @ ~/openembedded-core $ git log origin/dizzy --oneline 4621675 grub-efi: Add backslash lost from previous commit ac135bd grub-efi: Use the backport patch from grub 8687b8b license_class: Fix choose_lic_set into incompatible license 5f50f90 dpkg: Fix tarfix.patch 386898a dpkg: Fix for Fedora22 and new versions of tar c58814c oeqa/bbtests: Fix to ensure DL_DIR is set e443498 oeqa/bbtests: Fix race over DL_DIR and SSTATE_DIR are available in the git repository at: git://git.yoctoproject.org/poky-contrib akuster/dizzy-next http://git.yoctoproject.org/cgit.cgi//log/?h=akuster/dizzy-next Alejandro Hernandez (1): qemurunner: Improves checking for server and target IPs on qemus parameters Aníbal Limón (2): license_class: Fix choose_lic_set into incompatible license license_class: fix license.manifest shows LICENSE field differently to recipe Martin Jansa (2): connman-conf: fix SRC_URI_append license.bbclass: fix unexpected operator for LICENSE values with space Paul Eggleton (1): oeqa/utils/qemurunner: fix logging Petter Mabäcker (1): meta: set proper S value Richard Purdie (3): dpkg: Fix for Fedora22 and new versions of tar dpkg: Fix tarfix.patch grub-efi: Add backslash lost from previous commit Ross Burton (1): oeqa/QemuRunner: don't use bb for logging Saul Wold (1): grub-efi: Use the backport patch from grub Sona Sarmadi (4): bind9.9.5: CVE-2015-5477 qemu: CVE-2014-7840 qemu-vnc: CVE-2014-7815 qemu-slirp: CVE-2014-3640 Yi Zhao (1): oeqa/selftest: fix test_incremental_image_generation for changes in log output meta/classes/license.bbclass | 18 +++--- meta/lib/oeqa/selftest/buildoptions.py | 11 ++-- meta/lib/oeqa/utils/qemurunner.py | 73 -- meta/recipes-bsp/alsa-state/alsa-state.bb | 2 + meta/recipes-bsp/grub/grub-efi_2.00.bb | 1 + meta/recipes-bsp/hostap/hostap-conf_1.0.bb | 2 + meta/recipes-bsp/keymaps/keymaps_1.0.bb| 2 + .../bind/bind/bind9_9_5-CVE-2015-5477.patch| 45 + meta/recipes-connectivity/bind/bind_9.9.5.bb | 1 + meta/recipes-connectivity/connman/connman-conf.bb | 8 ++- .../ppp-dialin/ppp-dialin_0.1.bb | 2 + .../init-ifupdown/init-ifupdown_1.0.bb | 2 + .../initrdscripts/initramfs-boot_1.0.bb| 2 + .../initrdscripts/initramfs-framework_1.0.bb | 2 + .../initrdscripts/initramfs-live-boot_1.0.bb | 2 + .../initramfs-live-install-efi-testfs_1.0.bb | 2 + .../initramfs-live-install-efi_1.0.bb | 2 + .../initramfs-live-install-testfs_1.0.bb | 2 + .../initrdscripts/initramfs-live-install_1.0.bb| 2 + meta/recipes-core/initscripts/initscripts_1.0.bb | 2 + .../systemd/systemd-systemctl-native.bb| 2 + .../sysvinit/sysvinit-inittab_2.88dsf.bb | 2 +- meta/recipes-core/udev/udev-extraconf_1.1.bb | 2 + meta/recipes-devtools/dpkg/dpkg/tarfix.patch | 45 + meta/recipes-devtools/dpkg/dpkg_1.17.4.bb | 1 + meta/recipes-devtools/opkg/opkg-collateral.bb | 2 + .../recipes-devtools/qemu/qemu/CVE-2014-7840.patch | 57 + .../qemu/qemu/slirp-CVE-2014-3640.patch| 48 ++ .../qemu/qemu/vnc-CVE-2014-7815.patch | 53 meta/recipes-devtools/qemu/qemu_2.1.0.bb | 3 + .../run-postinsts/run-postinsts_1.0.bb | 2 + .../shadow/shadow-securetty_4.2.1.bb | 2 + .../xorg-xserver/xserver-xf86-config_0.1.bb| 2 + .../modutils-initscripts/modutils-initscripts.bb | 3 + meta/recipes-qt/qt-demo/qt-demo-init_0.1.bb| 2 + .../ptest-runner/ptest-runner_1.0.bb | 2 + 36 files changed, 361 insertions(+), 50 deletions(-) create mode 100644 meta/recipes-connectivity/bind/bind/bind9_9_5-CVE-2015-5477.patch create mode 100644 meta/recipes-devtools/dpkg/dpkg/tarfix.patch create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2014-7840.patch create mode 100644 meta/recipes-devtools/qemu/qemu/slirp-CVE-2014-3640.patch create mode 100644 meta/recipes-devtools/qemu/qemu/vnc-CVE-2014-7815.patch -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc
Re: [OE-core] [PATCH 00/17] For Dizzy 1.7.3a
Martin, I rebased against dizzy-next. It appears dizzy and dizzy-next are out of sync. I will rebase against dizzy. - armin On 08/28/2015 12:20 PM, Martin Jansa wrote: On Fri, Aug 28, 2015 at 12:16:04PM -0700, Armin Kuster wrote: Please consider these addition changes for Dizzy 1.7.3 The following changes since commit 86971b5d97645cdbf2e48c39f30afa7c44e81e81: oeqa/bbtests: Fix to ensure DL_DIR is set (2015-07-26 07:59:00 +) Some of these changes were already applied in dizzy, you should refresh your dizzy branch: OE @ ~/openembedded-core $ git log origin/dizzy --oneline 4621675 grub-efi: Add backslash lost from previous commit ac135bd grub-efi: Use the backport patch from grub 8687b8b license_class: Fix choose_lic_set into incompatible license 5f50f90 dpkg: Fix tarfix.patch 386898a dpkg: Fix for Fedora22 and new versions of tar c58814c oeqa/bbtests: Fix to ensure DL_DIR is set e443498 oeqa/bbtests: Fix race over DL_DIR and SSTATE_DIR are available in the git repository at: git://git.yoctoproject.org/poky-contrib akuster/dizzy-next http://git.yoctoproject.org/cgit.cgi//log/?h=akuster/dizzy-next Alejandro Hernandez (1): qemurunner: Improves checking for server and target IPs on qemus parameters Aníbal Limón (2): license_class: Fix choose_lic_set into incompatible license license_class: fix license.manifest shows LICENSE field differently to recipe Martin Jansa (2): connman-conf: fix SRC_URI_append license.bbclass: fix unexpected operator for LICENSE values with space Paul Eggleton (1): oeqa/utils/qemurunner: fix logging Petter Mabäcker (1): meta: set proper S value Richard Purdie (3): dpkg: Fix for Fedora22 and new versions of tar dpkg: Fix tarfix.patch grub-efi: Add backslash lost from previous commit Ross Burton (1): oeqa/QemuRunner: don't use bb for logging Saul Wold (1): grub-efi: Use the backport patch from grub Sona Sarmadi (4): bind9.9.5: CVE-2015-5477 qemu: CVE-2014-7840 qemu-vnc: CVE-2014-7815 qemu-slirp: CVE-2014-3640 Yi Zhao (1): oeqa/selftest: fix test_incremental_image_generation for changes in log output meta/classes/license.bbclass | 18 +++--- meta/lib/oeqa/selftest/buildoptions.py | 11 ++-- meta/lib/oeqa/utils/qemurunner.py | 73 -- meta/recipes-bsp/alsa-state/alsa-state.bb | 2 + meta/recipes-bsp/grub/grub-efi_2.00.bb | 1 + meta/recipes-bsp/hostap/hostap-conf_1.0.bb | 2 + meta/recipes-bsp/keymaps/keymaps_1.0.bb| 2 + .../bind/bind/bind9_9_5-CVE-2015-5477.patch| 45 + meta/recipes-connectivity/bind/bind_9.9.5.bb | 1 + meta/recipes-connectivity/connman/connman-conf.bb | 8 ++- .../ppp-dialin/ppp-dialin_0.1.bb | 2 + .../init-ifupdown/init-ifupdown_1.0.bb | 2 + .../initrdscripts/initramfs-boot_1.0.bb| 2 + .../initrdscripts/initramfs-framework_1.0.bb | 2 + .../initrdscripts/initramfs-live-boot_1.0.bb | 2 + .../initramfs-live-install-efi-testfs_1.0.bb | 2 + .../initramfs-live-install-efi_1.0.bb | 2 + .../initramfs-live-install-testfs_1.0.bb | 2 + .../initrdscripts/initramfs-live-install_1.0.bb| 2 + meta/recipes-core/initscripts/initscripts_1.0.bb | 2 + .../systemd/systemd-systemctl-native.bb| 2 + .../sysvinit/sysvinit-inittab_2.88dsf.bb | 2 +- meta/recipes-core/udev/udev-extraconf_1.1.bb | 2 + meta/recipes-devtools/dpkg/dpkg/tarfix.patch | 45 + meta/recipes-devtools/dpkg/dpkg_1.17.4.bb | 1 + meta/recipes-devtools/opkg/opkg-collateral.bb | 2 + .../recipes-devtools/qemu/qemu/CVE-2014-7840.patch | 57 + .../qemu/qemu/slirp-CVE-2014-3640.patch| 48 ++ .../qemu/qemu/vnc-CVE-2014-7815.patch | 53 meta/recipes-devtools/qemu/qemu_2.1.0.bb | 3 + .../run-postinsts/run-postinsts_1.0.bb | 2 + .../shadow/shadow-securetty_4.2.1.bb | 2 + .../xorg-xserver/xserver-xf86-config_0.1.bb| 2 + .../modutils-initscripts/modutils-initscripts.bb | 3 + meta/recipes-qt/qt-demo/qt-demo-init_0.1.bb| 2 + .../ptest-runner/ptest-runner_1.0.bb | 2 + 36 files changed, 361 insertions(+), 50 deletions(-) create mode 100644 meta/recipes-connectivity/bind/bind/bind9_9_5-CVE-2015-5477.patch create mode 100644 meta/recipes-devtools/dpkg/dpkg/tarfix.patch create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2014-7840.patch create mode 100644 meta/recipes-devtools/qemu/qemu/slirp-CVE-2014-3640.patch create mode 100644 meta/recipes-devtools/qemu/qemu/vnc-CVE-2014-7815.patch -- 1.9.1 -- ___ Openembedded-core mailing list
[OE-core] [PATCH 00/15] For Dizzy 1.7.3a v2
Rebased against Dizzy this time. Please consider this changes for Dizzy 1.7.3 The following changes since commit 137f52ac3a3cf6dc9eed27178c37e9ce235341d8: grub-efi: Add backslash lost from previous commit (2015-08-20 21:42:31 +0100) are available in the git repository at: git://git.yoctoproject.org/poky-contrib akuster/dizzy-next http://git.yoctoproject.org/cgit.cgi//log/?h=akuster/dizzy-next Alejandro Hernandez (1): qemurunner: Improves checking for server and target IPs on qemus parameters Aníbal Limón (1): license_class: fix license.manifest shows LICENSE field differently to recipe Martin Jansa (2): connman-conf: fix SRC_URI_append license.bbclass: fix unexpected operator for LICENSE values with space Paul Eggleton (1): oeqa/utils/qemurunner: fix logging Petter Mabäcker (1): meta: set proper S value Richard Purdie (3): runqueue: Add message to explain the problem if diffsigs multiple tasks don't exist fetch2: Extend mirroruri handlling sstate: Use SSTATE_DIR for FILESPATH Ross Burton (1): oeqa/QemuRunner: don't use bb for logging Sona Sarmadi (4): bind9.9.5: CVE-2015-5477 qemu: CVE-2014-7840 qemu-vnc: CVE-2014-7815 qemu-slirp: CVE-2014-3640 Yi Zhao (1): oeqa/selftest: fix test_incremental_image_generation for changes in log output bitbake/lib/bb/fetch2/__init__.py | 1 + bitbake/lib/bb/runqueue.py | 2 + meta/classes/license.bbclass | 15 ++--- meta/classes/sstate.bbclass| 4 +- meta/lib/oeqa/selftest/buildoptions.py | 11 ++-- meta/lib/oeqa/utils/qemurunner.py | 73 -- meta/recipes-bsp/alsa-state/alsa-state.bb | 2 + meta/recipes-bsp/hostap/hostap-conf_1.0.bb | 2 + meta/recipes-bsp/keymaps/keymaps_1.0.bb| 2 + .../bind/bind/bind9_9_5-CVE-2015-5477.patch| 45 + meta/recipes-connectivity/bind/bind_9.9.5.bb | 1 + meta/recipes-connectivity/connman/connman-conf.bb | 8 ++- .../ppp-dialin/ppp-dialin_0.1.bb | 2 + .../init-ifupdown/init-ifupdown_1.0.bb | 2 + .../initrdscripts/initramfs-boot_1.0.bb| 2 + .../initrdscripts/initramfs-framework_1.0.bb | 2 + .../initrdscripts/initramfs-live-boot_1.0.bb | 2 + .../initramfs-live-install-efi-testfs_1.0.bb | 2 + .../initramfs-live-install-efi_1.0.bb | 2 + .../initramfs-live-install-testfs_1.0.bb | 2 + .../initrdscripts/initramfs-live-install_1.0.bb| 2 + meta/recipes-core/initscripts/initscripts_1.0.bb | 2 + .../systemd/systemd-systemctl-native.bb| 2 + .../sysvinit/sysvinit-inittab_2.88dsf.bb | 2 +- meta/recipes-core/udev/udev-extraconf_1.1.bb | 2 + meta/recipes-devtools/opkg/opkg-collateral.bb | 2 + .../recipes-devtools/qemu/qemu/CVE-2014-7840.patch | 57 + .../qemu/qemu/slirp-CVE-2014-3640.patch| 48 ++ .../qemu/qemu/vnc-CVE-2014-7815.patch | 53 meta/recipes-devtools/qemu/qemu_2.1.0.bb | 3 + .../run-postinsts/run-postinsts_1.0.bb | 2 + .../shadow/shadow-securetty_4.2.1.bb | 2 + .../xorg-xserver/xserver-xf86-config_0.1.bb| 2 + .../modutils-initscripts/modutils-initscripts.bb | 3 + meta/recipes-qt/qt-demo/qt-demo-init_0.1.bb| 2 + .../ptest-runner/ptest-runner_1.0.bb | 2 + 36 files changed, 318 insertions(+), 50 deletions(-) create mode 100644 meta/recipes-connectivity/bind/bind/bind9_9_5-CVE-2015-5477.patch create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2014-7840.patch create mode 100644 meta/recipes-devtools/qemu/qemu/slirp-CVE-2014-3640.patch create mode 100644 meta/recipes-devtools/qemu/qemu/vnc-CVE-2014-7815.patch -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
