[OE-core] [PATCH] perf: fix build breakage on kernels after 4.1
A recent commit fixed perf build failures with a change that duplicates
a fix that can be found in kernels after 4.1. Unfortunately there is a
conflict between these two fixes and we see perf build failures when
building perf in kernels that contain the fix already. The problem is
that the fix from the recipe modifies the location of .config-detected
to $(OUTPUT).config-detected. In a 4.2 kernel the location will be
changed to $(OUTPUT)$(OUTPUT).config-detected.
We change the recipe to require a space in the pattern to only change
kernel sources that do not already place file in $(OUTPUT).
The recent commit that introduced the build failure is:
commit ea9016b60b47138bc58d84a06954b44527b20a19
Author: Richard Purdie richard.pur...@linuxfoundation.org
Date: Sat Jul 25 14:37:58 2015 +0100
perf: Fix config file conflict with 4.1 kernels
If you setup mutlitlibs and then:
bitbake perf libb32-perf
bitbake perf libb32-perf -c cleansstate
bitbake perf libb32-perf
you will see races where the two builds get confused about which
directory
they should be using and they corrupt each other.
The issue is that .config-detected is created in ${S}, not $(OUTPUT).
We can fix this by moving the file to $(OUTPUT).
[YCOTO #8043]
(From OE-Core rev: 00608cb586e8d2a2075117e710113c471448)
(From OE-Core rev: 57df1ebd910e42af47a0039830a60f41a3bd29b6)
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
The commit in the kernel source that fixes the problem from kernel side is:
commit 642273795fa81da11290ffa90bce6ff242f2a7bb
Author: Aaro Koskinen aaro.koski...@nokia.com
Date: Wed Jul 1 14:54:42 2015 +0300
perf tools: Create config.detected into OUTPUT directory
Create config.detected into OUTPUT directory instead of source
directory.
This fixes parallel builds that share the same source directory.
Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com
Acked-by: Jiri Olsa jo...@kernel.org
Cc: Paul Mackerras pau...@samba.org
Cc: Peter Zijlstra a.p.zijls...@chello.nl
Link:
http://lkml.kernel.org/r/1435751683-18500-1-git-send-email-aaro.koski...@nokia.com
Signed-off-by: Arnaldo Carvalho de Melo a...@redhat.com
Signed-off-by: Reinette Chatre reinette.cha...@intel.com
---
meta/recipes-kernel/perf/perf.bb | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/perf.bb
index f8e80d0..e7ddfff 100644
--- a/meta/recipes-kernel/perf/perf.bb
+++ b/meta/recipes-kernel/perf/perf.bb
@@ -134,6 +134,7 @@ do_configure_prepend () {
# config/Makefile.
#
# Also need to relocate .config-detected to $(OUTPUT)/config-detected
+# for kernel sources that do not already do this
# as two builds (e.g. perf and lib32-perf from mutlilib can conflict
# with each other if its in the shared source directory
#
@@ -141,15 +142,15 @@ do_configure_prepend () {
# Match $(prefix)/$(lib) and $(prefix)/lib
sed -i -e 's,^libdir = \($(prefix)/.*lib\),libdir ?= \1,' \
-e 's,^perfexecdir = \(.*\),perfexecdir ?= \1,' \
- -e 's,\.config-detected,$(OUTPUT)/config-detected,g' \
+ -e 's,\ .config-detected, $(OUTPUT)/config-detected,g' \
${S}/tools/perf/config/Makefile
fi
if [ -e ${S}/tools/perf/Makefile.perf ]; then
-sed -i -e 's,\.config-detected,$(OUTPUT)/config-detected,g' \
+sed -i -e 's,\ .config-detected, $(OUTPUT)/config-detected,g' \
${S}/tools/perf/Makefile.perf
fi
if [ -e ${S}/tools/build/Makefile.build ]; then
-sed -i -e 's,\.config-detected,$(OUTPUT)/config-detected,g' \
+sed -i -e 's,\ .config-detected, $(OUTPUT)/config-detected,g' \
${S}/tools/build/Makefile.build
fi
--
2.4.3
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] lib/oe/package_manager: Include PACKAGE_FEED_PREFIX instead of hardcode paths
From: Leonardo Sandoval leonardo.sandoval.gonza...@linux.intel.com
Instead of hardcode paths (/rpm/, /ipk/, /deb/), use a user-defined prefix
when creating the URI feeds. URIs now will have the following syntax:
PACKAGE_FEED_URIS_1/PACKAGE_FEED_PREFIX
PACKAGE_FEED_URIS_2/PACKAGE_FEED_PREFIX
.
where PACKAGE_FEED_URIS = PACKAGE_FEED_URIS_1 PACKAGE_FEED_URIS_2
[YOCTO #5407]
Signed-off-by: Leonardo Sandoval leonardo.sandoval.gonza...@linux.intel.com
---
meta/lib/oe/package_manager.py | 28 +++-
1 file changed, 19 insertions(+), 9 deletions(-)
diff --git a/meta/lib/oe/package_manager.py b/meta/lib/oe/package_manager.py
index 55b8ab0..7a85816 100644
--- a/meta/lib/oe/package_manager.py
+++ b/meta/lib/oe/package_manager.py
@@ -488,6 +488,7 @@ class PackageManager(object):
self.deploy_dir = None
self.deploy_lock = None
self.feed_uris = self.d.getVar('PACKAGE_FEED_URIS', True) or
+self.feed_prefix = self.d.getVar('PACKAGE_FEED_PREFIX', True) or
Update the package manager package database.
@@ -662,11 +663,14 @@ class RpmPM(PackageManager):
channel_priority = 10 + 5 * len(self.feed_uris.split()) *
len(arch_list)
for uri in self.feed_uris.split():
+full_uri = uri
+if self.feed_prefix:
+full_uri = os.path.join(uri, self.feed_prefix)
for arch in arch_list:
bb.note('Note: adding Smart channel url%d%s (%s)' %
(uri_iterator, arch, channel_priority))
-self._invoke_smart('channel --add url%d-%s type=rpm-md
baseurl=%s/rpm/%s -y'
- % (uri_iterator, arch, uri, arch))
+self._invoke_smart('channel --add url%d-%s type=rpm-md
baseurl=%s/%s -y'
+ % (uri_iterator, arch, full_uri, arch))
self._invoke_smart('channel --set url%d-%s priority=%d' %
(uri_iterator, arch, channel_priority))
channel_priority -= 5
@@ -1343,17 +1347,20 @@ class OpkgPM(PackageManager):
with open(rootfs_config, w+) as config_file:
uri_iterator = 0
for uri in self.feed_uris.split():
-config_file.write(src/gz url-%d %s/ipk\n %
- (uri_iterator, uri))
+full_uri = uri
+if self.feed_prefix:
+full_uri = os.path.join(uri, self.feed_prefix)
+config_file.write(src/gz url-%d %s\n %
+ (uri_iterator, full_uri))
for arch in self.pkg_archs.split():
if not os.path.exists(os.path.join(self.deploy_dir, arch)):
continue
bb.note('Note: adding opkg channel url-%s-%d (%s)' %
-(arch, uri_iterator, uri))
+(arch, uri_iterator, full_uri))
-config_file.write(src/gz uri-%s-%d %s/ipk/%s\n %
- (arch, uri_iterator, uri, arch))
+config_file.write(src/gz uri-%s-%d %s/%s\n %
+ (arch, uri_iterator, full_uri, arch))
uri_iterator += 1
def update(self):
@@ -1706,10 +1713,13 @@ class DpkgPM(PackageManager):
with open(sources_conf, w+) as sources_file:
for uri in self.feed_uris.split():
+full_uri = uri
+if self.feed_prefix:
+full_uri = os.path.join(uri, self.feed_prefix)
for arch in arch_list:
bb.note('Note: adding dpkg channel at (%s)' % uri)
-sources_file.write(deb %s/deb/%s ./\n %
- (uri, arch))
+sources_file.write(deb %s/%s ./\n %
+ (full_uri, arch))
def _create_configs(self, archs, base_archs):
base_archs = re.sub(_, -, base_archs)
--
1.7.10.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]
On Aug 11, 2015, at 1:36 PM, Burton, Ross ross.bur...@intel.com wrote: On 11 August 2015 at 16:46, Khem Raj raj.k...@gmail.com mailto:raj.k...@gmail.com wrote: can we freeze this thread please. Or more usefully, reboot it. Philip, you're turning into Koen! Alex, if someone on this list asks what Poky is, 99% of the time they're trolling. :) this ml it might be. But I interact with many folks who hear of it for first time and in general its quite confusing when you explain this to someone new. They get confused when they see yocto 1.8 and then poky 13.0, bitbake 1.26 and oe-core branched with codenames, poky distro layer is called meta-yocto and it also has BSPs in same repo, if you think from their POV its very confusing for some one new who is trying to get some understanding of this all. may be we can do without some of these now a days. but thats discussion for another day :) The original and unanswered question was should oe-core continue to maintain GPLv2 recipes where upstream has moved to GPLv3 or should those recipes move to a standalone layer with various implied questions: - If the v2 recipes move to a separate layer, who own/maintains/tests it? motivated enough to use OE some folks might come up but it won’t be same, at this time I know it gets more users for OE may be less developers but then look at patches to these components has come from users turned developers. We should also look into the case why glibc folded the secondary class architectures which were maintained in ports repository into glibc proper. - Should there be v2 recipes for every recipe that has moved to v3, or only (as is now) the more-core recipes (currently YP tests that core-image-base builds without GPLv3, nothing else more complicated) - Should meta-gplv2 only contain recipes from oe-core, or all layers? If other layers decide to hold both v3 and v2 recipes (not that I'm aware any have), what makes oe-core special? These are pertinent questions that I have raised earlier on thread that can cause more confusion to end user, but i think if we keep the check for choosing GPLv2 only packages in OE-Core and move these recipes to something like meta-legacy or something like that and not associate it with license name then we don’t have to worry about above questions. I'm torn, Richard is torn. Neither of those are useful to forming a decision. Does anyone else have any *useful* feedback? however it can be left in there if its not causing a lot of maintenance burden since it still serves a purpose downstream. Ross 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
[OE-core] [PATCH 1/1] meta-yocto-bsp: mpc8315e-rdb: Set KERNEL_DEVICETREE to mpc8315erdb.dtb
From: He Zhe zhe...@windriver.com
To avoid warning of xxx contains the full path to the the dts file,
but only the dtb name should be used., Set KERNEL_DEVICETREE to
mpc8315erdb.dtb
Signed-off-by: He Zhe zhe...@windriver.com
---
meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf
b/meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf
index f372f32..2beef48 100644
--- a/meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf
+++ b/meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf
@@ -25,7 +25,7 @@ XSERVER ?= xserver-xorg \
PREFERRED_VERSION_u-boot ?= v2013.07%
UBOOT_ENTRYPOINT = 0x
-KERNEL_DEVICETREE = ${S}/arch/powerpc/boot/dts/mpc8315erdb.dts
+KERNEL_DEVICETREE = mpc8315erdb.dtb
MACHINE_EXTRA_RRECOMMENDS = kernel-modules
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] meta-yocto-bsp: mpc8315e-rdb: Set KERNEL_DEVICETREE to mpc8315erdb.dtb
From: He Zhe zhe...@windriver.com The following changes since commit a16e0b4014173af46ef80d643bb71055219b0dab: bitbake: toaster: reduced amount of instance attributes (2015-08-10 13:58:02 -0700) are available in the git repository at: git://git.yoctoproject.org/poky-contrib zhe/kernel_devicetree http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=zhe/kernel_devicetree for you to fetch changes up to 648173de6f77371c4e0b803af12b23cd514b2d9f: meta-yocto-bsp: mpc8315e-rdb: Set KERNEL_DEVICETREE to mpc8315erdb.dtb (2015-08-11 04:58:28 -0400) He Zhe (1): meta-yocto-bsp: mpc8315e-rdb: Set KERNEL_DEVICETREE to mpc8315erdb.dtb meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] kernel: Correct mishandling of linux.bin for building uImage
From: He Zhe zhe...@windriver.com The following changes since commit a16e0b4014173af46ef80d643bb71055219b0dab: bitbake: toaster: reduced amount of instance attributes (2015-08-10 13:58:02 -0700) are available in the git repository at: git://git.yoctoproject.org/poky-contrib zhe/kernel-uboot http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=zhe/kernel-uboot for you to fetch changes up to 925eb33167a5510d9d2ec76b0d3e1c2f3f109008: kernel: Correct mishandling of linux.bin for building uImage (2015-08-11 03:37:27 -0400) He Zhe (1): kernel: Correct mishandling of linux.bin for building uImage meta/classes/kernel-uboot.bbclass | 1 - 1 file changed, 1 deletion(-) -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] kernel: Correct mishandling of linux.bin for building uImage
From: He Zhe zhe...@windriver.com
Building uImage fails when KEEPUIMAGE is not yes.
Remove wrong removal of linux.bin before compressing it.
Signed-off-by: He Zhe zhe...@windriver.com
---
meta/classes/kernel-uboot.bbclass | 1 -
1 file changed, 1 deletion(-)
diff --git a/meta/classes/kernel-uboot.bbclass
b/meta/classes/kernel-uboot.bbclass
index 8ab30b8..345e7f5 100644
--- a/meta/classes/kernel-uboot.bbclass
+++ b/meta/classes/kernel-uboot.bbclass
@@ -12,7 +12,6 @@ uboot_prep_kimage() {
${OBJCOPY} -O binary -R .note -R .comment -S ${vmlinux_path} linux.bin
if [ ${linux_comp} != none ] ; then
- rm -f linux.bin
gzip -9 linux.bin
mv -f linux.bin${linux_suffix} linux.bin
fi
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/3] tar-replacement-native: avoid race condition with host tar
Installing tar into the sysroot leads to race conditions
(tasks which do not depend on tar-replacement-native may already
call tar while it's installation is incomplete). Avoid those
by installing only the tar binary under the name tar-native.
Signed-off-by: Patrick Ohly patrick.o...@intel.com
---
meta/recipes-extended/tar/tar-replacement-native_1.28.bb | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-extended/tar/tar-replacement-native_1.28.bb
b/meta/recipes-extended/tar/tar-replacement-native_1.28.bb
index 071ede7..d69122f 100644
--- a/meta/recipes-extended/tar/tar-replacement-native_1.28.bb
+++ b/meta/recipes-extended/tar/tar-replacement-native_1.28.bb
@@ -3,4 +3,16 @@ require tar_${PV}.bb
inherit native
BPN = tar
-EXTRAINSTALL =
+
+# Installing tar into the sysroot leads to race conditions
+# (tasks which do not depend on tar-replacement-native may already
+# call tar while it's installation is incomplete). Avoid those
+# by installing only the tar binary under the name tar-native.
+EXTRAINSTALL = do_install_extra_native
+do_install_extra_native () {
+remove=$(ls -d ${D}/*)
+mv ${D}${bindir}/tar ${D}/tar-native
+rm -r $remove
+install -d ${D}${bindir}
+mv ${D}/tar-native ${D}${bindir}
+}
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [RFC PATCH 0/1] Fix runtime error with generated OPKG feeds
When playing around with automatically generated opkg feeds I noticed that
we're inserting a feed pointing to the root of ${DEPLOY_DIR}/ipk - however for
my builds that directory doesn't include a Packages.gz resulting in opkg
printing an error.
The following patch removes the code which inserts that feed entry.
Cheers,
Joshua
The following changes since commit 5094354a2811825e6d60963f03959daa349cab23:
bind: upgrade to 9.10.2-p3 (2015-08-09 15:14:32 -0700)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib joshuagl/opkg
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=joshuagl/opkg
Joshua Lock (1):
lib/oe/package_manager: fix opkg feed generation
meta/lib/oe/package_manager.py | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [RFC PATCH 1/1] lib/oe/package_manager: fix opkg feed generation
The insert_feed_uris() method of OpkgPM was creating an initial
entry in the feeds list which pointed to the root of the ipk
directory, however the on-device package manager can't consume
this feed resulting in runtime errors - therefore we remove the
code to generate that initial feed uri.
Signed-off-by: Joshua Lock joshua.l...@collabora.co.uk
---
meta/lib/oe/package_manager.py | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/meta/lib/oe/package_manager.py b/meta/lib/oe/package_manager.py
index 55b8ab0..2ab1d78 100644
--- a/meta/lib/oe/package_manager.py
+++ b/meta/lib/oe/package_manager.py
@@ -1343,13 +1343,10 @@ class OpkgPM(PackageManager):
with open(rootfs_config, w+) as config_file:
uri_iterator = 0
for uri in self.feed_uris.split():
-config_file.write(src/gz url-%d %s/ipk\n %
- (uri_iterator, uri))
-
for arch in self.pkg_archs.split():
if not os.path.exists(os.path.join(self.deploy_dir, arch)):
continue
-bb.note('Note: adding opkg channel url-%s-%d (%s)' %
+bb.note('Note: adding opkg feed url-%s-%d (%s)' %
(arch, uri_iterator, uri))
config_file.write(src/gz uri-%s-%d %s/ipk/%s\n %
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/3] image_types.bbclass: allow replacing tar command
Usually, the host's tar command is sufficient. However, special cases
like archiving xattrs depend on a modern GNU tar version. The new
IMAGE_CMD_TAR makes that possible, with xattrs given as example.
Signed-off-by: Patrick Ohly patrick.o...@intel.com
---
meta/classes/image_types.bbclass | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index cc789fc..752fd52 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -71,7 +71,18 @@ IMAGE_CMD_btrfs () {
IMAGE_CMD_squashfs = mksquashfs ${IMAGE_ROOTFS}
${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.squashfs ${EXTRA_IMAGECMD} -noappend
IMAGE_CMD_squashfs-xz = mksquashfs ${IMAGE_ROOTFS}
${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.squashfs-xz ${EXTRA_IMAGECMD}
-noappend -comp xz
IMAGE_CMD_squashfs-lzo = mksquashfs ${IMAGE_ROOTFS}
${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.squashfs-lzo ${EXTRA_IMAGECMD}
-noappend -comp lzo
-IMAGE_CMD_tar = tar -cvf ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.tar -C
${IMAGE_ROOTFS} .
+
+# By default, tar from the host is used, which can be quite old. If
+# you need special parameters (like --xattrs) which are only supported
+# by GNU tar upstream = 1.27, then override that default:
+# IMAGE_CMD_TAR = tar-native --xattrs --xattrs-include=*
+# IMAGE_DEPENDS_tar_append = tar-replacement-native
+#
+# The GNU documentation does not specify whether --xattrs-include is necessary.
+# In practice, it turned out to be not needed when creating archives and
+# required when extracting, but it seems prudent to use it in both cases.
+IMAGE_CMD_TAR ?= tar
+IMAGE_CMD_tar = ${IMAGE_CMD_TAR} -cvf
${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.tar -C ${IMAGE_ROOTFS} .
do_rootfs[cleandirs] += ${WORKDIR}/cpio_append
IMAGE_CMD_cpio () {
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/3] mtd-utils: keep xattr support enabled
xattrs may be needed by some distros. Support that by compiling in the
necessary code, even if it is not used by default. Then .jffs2 images
including xattrs can be created with:
EXTRA_IMAGECMD_jffs2_append = --with-xattr
Signed-off-by: Patrick Ohly patrick.o...@intel.com
---
meta/recipes-devtools/mtd/mtd-utils_git.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/mtd/mtd-utils_git.bb
b/meta/recipes-devtools/mtd/mtd-utils_git.bb
index 7010cac..8d4892a 100644
--- a/meta/recipes-devtools/mtd/mtd-utils_git.bb
+++ b/meta/recipes-devtools/mtd/mtd-utils_git.bb
@@ -19,7 +19,7 @@ SRC_URI = git://git.infradead.org/mtd-utils.git \
S = ${WORKDIR}/git/
-EXTRA_OEMAKE = 'CC=${CC}' 'RANLIB=${RANLIB}' 'AR=${AR}' 'CFLAGS=${CFLAGS}
-I${S}/include -DWITHOUT_XATTR' 'BUILDDIR=${S}'
+EXTRA_OEMAKE = 'CC=${CC}' 'RANLIB=${RANLIB}' 'AR=${AR}' 'CFLAGS=${CFLAGS}
-I${S}/include' 'BUILDDIR=${S}'
do_install () {
oe_runmake install DESTDIR=${D} SBINDIR=${sbindir} MANDIR=${mandir}
INCLUDEDIR=${includedir}
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/3] preserve xattrs in images
Both Smack and IMA/EVM rely on xattrs in the rootfs. This works for .ext3/.ext4 images, but not for .jffs2 and .tar.bz2. These changes allow optionally building also such images with xattrs without changing the default (which still is to ignore xattrs in .jffs2 and .tar.bz2). The default does not get changed because supporting xattrs causes a certain overhead (need to build GNU tar, additional system calls when creating the images). See https://github.com/01org/meta-intel-iot-security/pull/34 for code using these changes. The following changes since commit 5094354a2811825e6d60963f03959daa349cab23: bind: upgrade to 9.10.2-p3 (2015-08-09 15:14:32 -0700) are available in the git repository at: git://github.com/pohly/openembedded-core xattr https://github.com/pohly/openembedded-core/tree/xattr Patrick Ohly (3): tar-replacement-native: avoid race condition with host tar image_types.bbclass: allow replacing tar command mtd-utils: keep xattr support enabled meta/classes/image_types.bbclass | 13 - meta/recipes-devtools/mtd/mtd-utils_git.bb | 2 +- meta/recipes-extended/tar/tar-replacement-native_1.28.bb | 14 +- 3 files changed, 26 insertions(+), 3 deletions(-) -- 2.1.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] kernel.bbclass: Fix do_shared_workdir task ordering
On Tue, Aug 11, 2015 at 9:06 AM, Bruce Ashfield bruce.ashfi...@gmail.com wrote: On Tue, Aug 11, 2015 at 8:47 AM, Otavio Salvador otavio.salva...@ossystems.com.br wrote: On Tue, Aug 11, 2015 at 12:23 AM, Bruce Ashfield bruce.ashfi...@gmail.com wrote: On Mon, Aug 10, 2015 at 11:21 AM, Stefan Müller-Klieser s.mueller-klie...@phytec.de wrote: commit 02d0a003d60326 [kernel.bbclass: Fix race condition] has surfaced a bug in the generation of the shared_workdir. The task do_compile_kernelmodules adds the exported symbols of the kernel modules to the Module.symvers. By creating the shared_workdir before the modules are compiled, the symbols of the modules are missing in the shared_workdir. Subsequent external module builds will not include the ABI CRC of functions exported in modules. Modprobe will fail to load the external module if CONFIG_MODVERSIONS is enabled.\ Have you seen our bug: https://bugzilla.yoctoproject.org/show_bug.cgi?id=8127 ? It's new .. so probably not. The significant issue with this, is that we are now forcing anyone that needs the shared workdir artifacts to build kernel modules. That's performance issue for many workflows. I had some changes where I was working to short cut parts of the process, but they turned out to miss a few corner cases. We need to do more thinking on this one, before we can bring in a change like this .. since avoiding that overhead is something valuable. I agree that performance is important but correctness seems more valuable for me. I think the optimization can come as a subsequent patch ... Let's disagree on this point. There's time to get this right. We have a bug to track it, so we wont' release with the active bug, and this only hits a very tiny set of users. So we are going to step back and try and fix this right. I hit send too soon. I have a suggestion in the bug already, so it isn't like we are talking about letting this sit for weeks. History shows that we are very unlikely to loop back and fix the performance of perf or other builds once the change goes in. So in the absence of other concrete suggestions, looking into some other small changes is a good use of time. Cheers, Bruce Bruce -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 -- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end -- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] kernel.bbclass: Fix do_shared_workdir task ordering
On Tue, Aug 11, 2015 at 8:47 AM, Otavio Salvador otavio.salva...@ossystems.com.br wrote: On Tue, Aug 11, 2015 at 12:23 AM, Bruce Ashfield bruce.ashfi...@gmail.com wrote: On Mon, Aug 10, 2015 at 11:21 AM, Stefan Müller-Klieser s.mueller-klie...@phytec.de wrote: commit 02d0a003d60326 [kernel.bbclass: Fix race condition] has surfaced a bug in the generation of the shared_workdir. The task do_compile_kernelmodules adds the exported symbols of the kernel modules to the Module.symvers. By creating the shared_workdir before the modules are compiled, the symbols of the modules are missing in the shared_workdir. Subsequent external module builds will not include the ABI CRC of functions exported in modules. Modprobe will fail to load the external module if CONFIG_MODVERSIONS is enabled.\ Have you seen our bug: https://bugzilla.yoctoproject.org/show_bug.cgi?id=8127 ? It's new .. so probably not. The significant issue with this, is that we are now forcing anyone that needs the shared workdir artifacts to build kernel modules. That's performance issue for many workflows. I had some changes where I was working to short cut parts of the process, but they turned out to miss a few corner cases. We need to do more thinking on this one, before we can bring in a change like this .. since avoiding that overhead is something valuable. I agree that performance is important but correctness seems more valuable for me. I think the optimization can come as a subsequent patch ... Let's disagree on this point. There's time to get this right. We have a bug to track it, so we wont' release with the active bug, and this only hits a very tiny set of users. So we are going to step back and try and fix this right. Bruce -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 -- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] base.bbclass/blacklist.bbclass: remove doc item when d.getVarFlags()
On Thu, Jul 30, 2015 at 12:18 PM, Robert Yang liezhi.y...@windriver.com wrote: The FOO[doc] is set in meta/conf/documentation.conf, we need remove it from d.getVarFlags()'s return dict when it causes many loops. Signed-off-by: Robert Yang liezhi.y...@windriver.com It seems your commit log is incomplete or so as I couldn't understand why this is need. Also as Andre says, we ought to not break existing layer without a very strong reason and if needed, changing documentation.conf instead of this seems more adequate. -- 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] kernel.bbclass: Fix do_shared_workdir task ordering
On Tue, Aug 11, 2015 at 12:23 AM, Bruce Ashfield bruce.ashfi...@gmail.com wrote: On Mon, Aug 10, 2015 at 11:21 AM, Stefan Müller-Klieser s.mueller-klie...@phytec.de wrote: commit 02d0a003d60326 [kernel.bbclass: Fix race condition] has surfaced a bug in the generation of the shared_workdir. The task do_compile_kernelmodules adds the exported symbols of the kernel modules to the Module.symvers. By creating the shared_workdir before the modules are compiled, the symbols of the modules are missing in the shared_workdir. Subsequent external module builds will not include the ABI CRC of functions exported in modules. Modprobe will fail to load the external module if CONFIG_MODVERSIONS is enabled.\ Have you seen our bug: https://bugzilla.yoctoproject.org/show_bug.cgi?id=8127 ? It's new .. so probably not. The significant issue with this, is that we are now forcing anyone that needs the shared workdir artifacts to build kernel modules. That's performance issue for many workflows. I had some changes where I was working to short cut parts of the process, but they turned out to miss a few corner cases. We need to do more thinking on this one, before we can bring in a change like this .. since avoiding that overhead is something valuable. I agree that performance is important but correctness seems more valuable for me. I think the optimization can come as a subsequent patch ... -- 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] meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]
On 08/10/2015 10:15 PM, Philip Balister wrote: This is perfectly fine with me. However, the subject has been whether the scope of *oe-core/poky* can be expanded without compromising What is Poky? Uhm... http://git.yoctoproject.org/cgit/cgit.cgi/poky/about/ Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] wic: Add plugin for hybrid iso image
Hi Mihaly, Great work! Thank you! Acked-by: Ed Bartosh ed.bart...@linux.intel.com On Thu, Aug 06, 2015 at 08:04:49PM +0300, Mihaly Varga wrote: Hi Ed, Thank you for your comments. There is a slightly modified version of the isoimage-isohybrid plugin, the kickstart file and the wic selftest extended with the iso image creation test case. On 7/28/2015 1:57 PM, Ed Bartosh wrote: Hi Mihaly, The code looks ok to me. Can you please fix the following: 1. Pylint is reporting a lot of long lines, indentation and other issues, so it would be nice if you run it and fix at least some of them? 2. Docstring of plugin class is shown in 'wic help plugins' output. Some lines of your plugins look very long there. Please, reformat them. 3. kickstart.get_timeout has a parameter to specify default timeout value. You can use that instead of assigning default value in the code. 4. Using names prefixed by two underscores is only needed if you're really concerned about the name and want it to be mangled by python. One underscore is more than enough in most cases. 5. Please add test case(s) for your plugin to meta/lib/oeqa/selftest/wic.py. This can help keeping your plugin in working state as yocto autobuilder regularly runs all tests. 6. What's crdtools and how to bake them? This is a typo in the commit message, is about cdrtools program set, which contains the mkisofs program. I corrected the commit message. Best regards Mihaly -- -- Regards, Ed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] mc: Fix QA warning RDEPENDS of util-linux-libmount
On 11 August 2015 at 00:54, Andre McCurdy armccu...@gmail.com wrote: I guess adding util-linux to DEPENDS would be the correct fix. The runtime dependency on libmount will then be detected automatically. Yes, that's right. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCHv2] mc: Fix QA warning RDEPENDS of util-linux-libmount
On 11 August 2015 at 15:57, Aníbal Limón anibal.li...@linux.intel.com
wrote:
+RDEPENDS_${PN} = ncurses-terminfo util-linux
DEPENDS, no RDEPENDS.
Ross
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCHv2] mc: Fix QA warning RDEPENDS of util-linux-libmount
The QA warnings saya mc rdepends on util-linux-libmount,
May be the QA message need to be fixed.
alimon
On 11/08/15 09:59, Burton, Ross wrote:
On 11 August 2015 at 15:57, Aníbal Limón anibal.li...@linux.intel.com
wrote:
+RDEPENDS_${PN} = ncurses-terminfo util-linux
DEPENDS, no RDEPENDS.
Ross
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] kernel.bbclass: Fix do_shared_workdir task ordering
On Tue, Aug 11, 2015 at 10:25 AM, Stefan Müller-Klieser s.mueller-klie...@phytec.de wrote: On 11.08.2015 15:11, Bruce Ashfield wrote: On Tue, Aug 11, 2015 at 9:06 AM, Bruce Ashfield bruce.ashfi...@gmail.com wrote: On Tue, Aug 11, 2015 at 8:47 AM, Otavio Salvador otavio.salva...@ossystems.com.br wrote: On Tue, Aug 11, 2015 at 12:23 AM, Bruce Ashfield bruce.ashfi...@gmail.com wrote: On Mon, Aug 10, 2015 at 11:21 AM, Stefan Müller-Klieser s.mueller-klie...@phytec.de wrote: commit 02d0a003d60326 [kernel.bbclass: Fix race condition] has surfaced a bug in the generation of the shared_workdir. The task do_compile_kernelmodules adds the exported symbols of the kernel modules to the Module.symvers. By creating the shared_workdir before the modules are compiled, the symbols of the modules are missing in the shared_workdir. Subsequent external module builds will not include the ABI CRC of functions exported in modules. Modprobe will fail to load the external module if CONFIG_MODVERSIONS is enabled.\ Have you seen our bug: https://bugzilla.yoctoproject.org/show_bug.cgi?id=8127 ? It's new .. so probably not. I did not. Thanks. The significant issue with this, is that we are now forcing anyone that needs the shared workdir artifacts to build kernel modules. That's by design. The artifacts are modified by the module build. As was the generating of shared workdir being before the module build .. but yes, we are aware of how and why the kernel build generates those artifacts. That's performance issue for many workflows. I had some changes where I was working to short cut parts of the process, but they turned out to miss a few corner cases. We need to do more thinking on this one, before we can bring in a change like this .. since avoiding that overhead is something valuable. So you are saying a fast build is more important than a correct build? That's quite a bold statement. That's not what I said. I agree that performance is important but correctness seems more valuable for me. I think the optimization can come as a subsequent patch ... Let's disagree on this point. There's time to get this right. We have a bug to track it, so we wont' release with the active bug, and this only hits a very tiny set of users. So we are going to step back and try and fix this right. Well, if you really want to do this then there should at least be a module-interdepend.bbclass not using the shared workdir and depending on the modules build. Fido and master are broken at the moment. There's multiple ways to consider here and not a single right way. But if you have an idea, send patch for review, or update the bug I referenced, that way we can consider them as well. I'm not saying this isn't a bug or issue, I'm saying that it hits a certain set of builds (and not all), so fixing this in a way that doesn't break the other design goals of the kernel build is important as well. I end up getting the bugs, and having to fix performance issues ... so I'm sensitive to all the use cases. We've been back and forth on the shared artefacts generation, with a lot of unintended side effects. Any changes in this area have to soak and be looked at by as many eyes as possible. RP may grab this as is, and that's also fine with me, I'm just on the record pointing out the side effects, so when someone notices incremental builds, or sstate, or updates taking longer .. we can point to the reason why. Bruce Regards, Stefan I hit send too soon. I have a suggestion in the bug already, so it isn't like we are talking about letting this sit for weeks. History shows that we are very unlikely to loop back and fix the performance of perf or other builds once the change goes in. So in the absence of other concrete suggestions, looking into some other small changes is a good use of time. Cheers, Bruce Bruce -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 -- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end -- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [VAC] Out of office for some days
Hello folks, I want to inform that I will be out of office for some days. From August 12th to August 25th I will be visiting London and will be reading the e-mail sporadically. For the fixes related to Freescale related layers, I will be able to merge things if urgent fixes are done. Otherwise I will delay the merge and review for when I am back. Best Regards, -- 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] [PATCH v2] create-pull-request: cd to relative directory
create-pull-request -d path creates empty patches if directory is specified as a path, i.e. ./bitbake or ./bitbake/ or full path. It behaves expected way only if script is run with -d bitbake, i.e. relative dir name doesn't contain '\'. Fixed this unwanted behaviour by changing directory and running git format-patch in it with --relative, without specifying relative path as a parameter. Signed-off-by: Ed Bartosh ed.bart...@linux.intel.com --- scripts/create-pull-request | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/scripts/create-pull-request b/scripts/create-pull-request index 216edfd..786fd1ed 100755 --- a/scripts/create-pull-request +++ b/scripts/create-pull-request @@ -177,12 +177,16 @@ mkdir $ODIR if [ -n $RELDIR ]; then ODIR=$(realpath $ODIR) - extraopts=--relative=$RELDIR + prevdir=$(pwd) + cd $RELDIR + extraopts=--relative fi # Generate the patches and cover letter git format-patch $extraopts -M40 --subject-prefix=$PREFIX -n -o $ODIR --thread=shallow --cover-letter $RELATIVE_TO..$COMMIT_ID /dev/null +[ -n $RELDIR ] cd $prevdir + # Customize the cover letter CL=$ODIR/-cover-letter.patch PM=$ODIR/pull-msg -- 2.1.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/3] preserve xattrs in images
Hi Patrick, On 11 August 2015 at 09:44, Patrick Ohly patrick.o...@intel.com wrote: The default does not get changed because supporting xattrs causes a certain overhead (need to build GNU tar, additional system calls when creating the images). Two questions: 1) Do enough host distributions not enable xattrs in tar that we need to depend on tar-replacement-native? 2) Have you timed the overhead of enabling xattr archiving on an image that doesn't use xattrs? (subtext: does this need to be an option). Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] base.bbclass/blacklist.bbclass: remove doc item when d.getVarFlags()
On 11 August 2015 at 03:17, Robert Yang liezhi.y...@windriver.com wrote: I'm afraid that there isn't any other way to fix the issue (many unneeded loops caused by PACKAGECONFIG[doc] which is set by documentation.conf), maybe you can change 'doc' to such as 'docs' in other layers ? Otavio is right - the commit doesn't explain what the problem is, and forcibly deleting PACKAGECONFIG[doc] options is very aggressive without good reason. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCHv3] mc: Fix QA warning depends on util-linux
mc depends on util-linux that uses libmount for mount filesystems.
Signed-off-by: Aníbal Limón anibal.li...@linux.intel.com
---
meta/recipes-extended/mc/mc_4.8.14.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-extended/mc/mc_4.8.14.bb
b/meta/recipes-extended/mc/mc_4.8.14.bb
index 8fec0b3..3b6c2ff 100644
--- a/meta/recipes-extended/mc/mc_4.8.14.bb
+++ b/meta/recipes-extended/mc/mc_4.8.14.bb
@@ -3,7 +3,7 @@ HOMEPAGE = http://www.midnight-commander.org/;
LICENSE = GPLv3
LIC_FILES_CHKSUM = file://COPYING;md5=270bbafe360e73f9840bd7981621f9c2
SECTION = console/utils
-DEPENDS = ncurses glib-2.0
+DEPENDS = ncurses glib-2.0 util-linux
RDEPENDS_${PN} = ncurses-terminfo
SRC_URI = http://www.midnight-commander.org/downloads/${BPN}-${PV}.tar.bz2 \
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] kernel.bbclass: Fix do_shared_workdir task ordering
On 11.08.2015 15:11, Bruce Ashfield wrote: On Tue, Aug 11, 2015 at 9:06 AM, Bruce Ashfield bruce.ashfi...@gmail.com wrote: On Tue, Aug 11, 2015 at 8:47 AM, Otavio Salvador otavio.salva...@ossystems.com.br wrote: On Tue, Aug 11, 2015 at 12:23 AM, Bruce Ashfield bruce.ashfi...@gmail.com wrote: On Mon, Aug 10, 2015 at 11:21 AM, Stefan Müller-Klieser s.mueller-klie...@phytec.de wrote: commit 02d0a003d60326 [kernel.bbclass: Fix race condition] has surfaced a bug in the generation of the shared_workdir. The task do_compile_kernelmodules adds the exported symbols of the kernel modules to the Module.symvers. By creating the shared_workdir before the modules are compiled, the symbols of the modules are missing in the shared_workdir. Subsequent external module builds will not include the ABI CRC of functions exported in modules. Modprobe will fail to load the external module if CONFIG_MODVERSIONS is enabled.\ Have you seen our bug: https://bugzilla.yoctoproject.org/show_bug.cgi?id=8127 ? It's new .. so probably not. I did not. Thanks. The significant issue with this, is that we are now forcing anyone that needs the shared workdir artifacts to build kernel modules. That's by design. The artifacts are modified by the module build. That's performance issue for many workflows. I had some changes where I was working to short cut parts of the process, but they turned out to miss a few corner cases. We need to do more thinking on this one, before we can bring in a change like this .. since avoiding that overhead is something valuable. So you are saying a fast build is more important than a correct build? That's quite a bold statement. I agree that performance is important but correctness seems more valuable for me. I think the optimization can come as a subsequent patch ... Let's disagree on this point. There's time to get this right. We have a bug to track it, so we wont' release with the active bug, and this only hits a very tiny set of users. So we are going to step back and try and fix this right. Well, if you really want to do this then there should at least be a module-interdepend.bbclass not using the shared workdir and depending on the modules build. Fido and master are broken at the moment. Regards, Stefan I hit send too soon. I have a suggestion in the bug already, so it isn't like we are talking about letting this sit for weeks. History shows that we are very unlikely to loop back and fix the performance of perf or other builds once the change goes in. So in the absence of other concrete suggestions, looking into some other small changes is a good use of time. Cheers, Bruce Bruce -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 -- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3] create-pull-request: cd to relative directory
create-pull-request -d path creates empty patches if directory is specified as a path, i.e. ./bitbake or ./bitbake/ or full path. It behaves expected way only if script is run with -d bitbake, i.e. relative dir name doesn't contain '\'. Fixed this unwanted behaviour by changing directory and running git format-patch in it with --relative, without specifying relative path as a parameter. Signed-off-by: Ed Bartosh ed.bart...@linux.intel.com --- scripts/create-pull-request | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/scripts/create-pull-request b/scripts/create-pull-request index 216edfd..786fd1ed 100755 --- a/scripts/create-pull-request +++ b/scripts/create-pull-request @@ -177,12 +177,16 @@ mkdir $ODIR if [ -n $RELDIR ]; then ODIR=$(realpath $ODIR) - extraopts=--relative=$RELDIR + prevdir=$(pwd) + cd $RELDIR + extraopts=--relative fi # Generate the patches and cover letter git format-patch $extraopts -M40 --subject-prefix=$PREFIX -n -o $ODIR --thread=shallow --cover-letter $RELATIVE_TO..$COMMIT_ID /dev/null +[ -n $RELDIR ] cd $prevdir + # Customize the cover letter CL=$ODIR/-cover-letter.patch PM=$ODIR/pull-msg -- 2.1.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/3] mtd-utils: keep xattr support enabled
On 11 August 2015 at 09:45, Patrick Ohly patrick.o...@intel.com wrote:
-EXTRA_OEMAKE = 'CC=${CC}' 'RANLIB=${RANLIB}' 'AR=${AR}'
'CFLAGS=${CFLAGS} -I${S}/include -DWITHOUT_XATTR' 'BUILDDIR=${S}'
+EXTRA_OEMAKE = 'CC=${CC}' 'RANLIB=${RANLIB}' 'AR=${AR}'
'CFLAGS=${CFLAGS} -I${S}/include' 'BUILDDIR=${S}'
There's a xattr DISTRO_FEATURE that should be respected here for target
builds (and explicitly enabled for native I guess).
Does enabling xattr mean adding build dependencies?
Ross
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCHv2] mc: Fix QA warning RDEPENDS of util-linux-libmount
mc depends on libmount that uses for try to mount filesystems.
Signed-off-by: Aníbal Limón anibal.li...@linux.intel.com
---
meta/recipes-extended/mc/mc_4.8.14.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-extended/mc/mc_4.8.14.bb
b/meta/recipes-extended/mc/mc_4.8.14.bb
index 8fec0b3..e662a9b 100644
--- a/meta/recipes-extended/mc/mc_4.8.14.bb
+++ b/meta/recipes-extended/mc/mc_4.8.14.bb
@@ -4,7 +4,7 @@ LICENSE = GPLv3
LIC_FILES_CHKSUM = file://COPYING;md5=270bbafe360e73f9840bd7981621f9c2
SECTION = console/utils
DEPENDS = ncurses glib-2.0
-RDEPENDS_${PN} = ncurses-terminfo
+RDEPENDS_${PN} = ncurses-terminfo util-linux
SRC_URI = http://www.midnight-commander.org/downloads/${BPN}-${PV}.tar.bz2 \
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] blktool: update to 4-7
This means replacing a -6.1 Debian patch with -7 patch.
Signed-off-by: Alexander Kanavin alexander.kana...@linux.intel.com
---
.../blktool/0001-fix-typos-in-manpage.patch| 40 +++
.../blktool/blktool/0002-fix-string-error.patch| 31 +
...rgument-for-BLKROSET-it-must-be-const-int.patch | 78 ++
.../blktool/{blktool_4-6.1.bb = blktool_4-7.bb} | 9 ++-
4 files changed, 153 insertions(+), 5 deletions(-)
create mode 100644
meta/recipes-extended/blktool/blktool/0001-fix-typos-in-manpage.patch
create mode 100644
meta/recipes-extended/blktool/blktool/0002-fix-string-error.patch
create mode 100644
meta/recipes-extended/blktool/blktool/0003-Fix-3-d-argument-for-BLKROSET-it-must-be-const-int.patch
rename meta/recipes-extended/blktool/{blktool_4-6.1.bb = blktool_4-7.bb} (76%)
diff --git
a/meta/recipes-extended/blktool/blktool/0001-fix-typos-in-manpage.patch
b/meta/recipes-extended/blktool/blktool/0001-fix-typos-in-manpage.patch
new file mode 100644
index 000..fee368d
--- /dev/null
+++ b/meta/recipes-extended/blktool/blktool/0001-fix-typos-in-manpage.patch
@@ -0,0 +1,40 @@
+From 9cb1667f9d3a9bcfc3b83466cd8d3b79f0554ff0 Mon Sep 17 00:00:00 2001
+From: Azat Khuzhin a3at.m...@gmail.com
+Date: Wed, 8 Jul 2015 01:37:09 +0300
+Subject: [PATCH 1/3] fix typos in manpage
+
+This patch is taken from
+ftp://ftp.debian.org/debian/pool/main/b/blktool/blktool_4-7.debian.tar.xz
+
+Upstream-Status: Inappropriate [upstream is dead]
+Signed-off-by: Alexander Kanavin alexander.kana...@linux.intel.com
+
+---
+ blktool.8 | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/blktool.8 b/blktool.8
+index a1f5c96..45b7724 100644
+--- a/blktool.8
b/blktool.8
+@@ -191,7 +191,7 @@ Query or set device bus state (0 off, 1 on, 2 tristate)
+ Query the detected (or overridden, via -t) device class.
+ Typically this will result in 'ATA' or 'SCSI' for most devices.
+ Detection is based on device major; thus your SATA device may appear as
+-'SCSI'.
++\'SCSI'.
+
+ .TP
+ .B cd-speed
+@@ -237,7 +237,7 @@ Omitting the on/off argument will print the current state.
+
+ .TP
+ .B media
+-Lock in (or unlock) a removeable device.
++Lock in (or unlock) a removable device.
+
+ .TP
+ .B multiple-count
+--
+2.1.4
+
diff --git a/meta/recipes-extended/blktool/blktool/0002-fix-string-error.patch
b/meta/recipes-extended/blktool/blktool/0002-fix-string-error.patch
new file mode 100644
index 000..d08aba5
--- /dev/null
+++ b/meta/recipes-extended/blktool/blktool/0002-fix-string-error.patch
@@ -0,0 +1,31 @@
+From ddb1071da2c78d8155aab62e9f0d46f69500200f Mon Sep 17 00:00:00 2001
+From: Azat Khuzhin a3at.m...@gmail.com
+Date: Wed, 8 Jul 2015 01:42:24 +0300
+Subject: [PATCH 2/3] fix string error
+
+This patch is taken from
+ftp://ftp.debian.org/debian/pool/main/b/blktool/blktool_4-7.debian.tar.xz
+
+Upstream-Status: Inappropriate [upstream is dead]
+Signed-off-by: Alexander Kanavin alexander.kana...@linux.intel.com
+
+---
+ util.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/util.c b/util.c
+index 1f3a9ca..2ccf56a 100644
+--- a/util.c
b/util.c
+@@ -28,7 +28,7 @@ void pdie(const char *msg, int perr)
+ if (perr)
+ perror(msg);
+ else
+- fprintf(stderr, msg);
++ fprintf(stderr, %s, msg);
+ if (blkdev = 0)
+ close(blkdev);
+ exit(1);
+--
+2.1.4
+
diff --git
a/meta/recipes-extended/blktool/blktool/0003-Fix-3-d-argument-for-BLKROSET-it-must-be-const-int.patch
b/meta/recipes-extended/blktool/blktool/0003-Fix-3-d-argument-for-BLKROSET-it-must-be-const-int.patch
new file mode 100644
index 000..d7ed0b9
--- /dev/null
+++
b/meta/recipes-extended/blktool/blktool/0003-Fix-3-d-argument-for-BLKROSET-it-must-be-const-int.patch
@@ -0,0 +1,78 @@
+From 68faa63aaad81f4a289e4a03173ab4cf798deb53 Mon Sep 17 00:00:00 2001
+From: Azat Khuzhin a3at.m...@gmail.com
+Date: Sat, 1 Nov 2014 22:24:32 +0300
+Subject: [PATCH 3/3] Fix 3-d argument for BLKROSET it must be 'const int *'
+
+Most of *SET ioctls have int type for 3-d argument, except BLKROSET.
+So add bc_arg_type enum, build it into bool_comand and install arg_type
+to bc_arg_int_ptr for BLKROSET only.
+
+Debian-bug-id: 641164
+Link: https://bugs.debian.org/641164
+
+This patch is taken from
+ftp://ftp.debian.org/debian/pool/main/b/blktool/blktool_4-7.debian.tar.xz
+
+Upstream-Status: Inappropriate [upstream is dead]
+Signed-off-by: Alexander Kanavin alexander.kana...@linux.intel.com
+
+---
+ blktool.c | 11 +--
+ blktool.h | 7 +++
+ 2 files changed, 16 insertions(+), 2 deletions(-)
+
+diff --git a/blktool.c b/blktool.c
+index fbefecd..221a195 100644
+--- a/blktool.c
b/blktool.c
+@@ -85,7 +85,7 @@ static struct bool_command bool_cmd_tbl[] = {
+ { { DEF_BOOL(pio-data), dc_ata, DEF_HDIO(32BIT) },
+ 16-bit, 32-bit },
+ { { DEF_BOOL(readonly), dc_any, IOCNAME(BLKROGET), IOCNAME(BLKROSET)
},
+-
[OE-core] [PATCH 1/2] apmd: update to 3.2.2-15
This basically means replacing a -14 Debian patch with -15 patch.
Signed-off-by: Alexander Kanavin alexander.kana...@linux.intel.com
---
.../apmd/{apmd-3.2.2-14 = apmd}/apmd.service | 0
.../apmd/{apmd-3.2.2-14 = apmd}/apmd_proxy| 0
.../apmd/{apmd-3.2.2-14 = apmd}/apmd_proxy.conf | 0
.../apmd/{apmd-3.2.2-14 = apmd}/default | 0
meta/recipes-bsp/apmd/{apmd-3.2.2-14 = apmd}/init | 0
meta/recipes-bsp/apmd/apmd/legacy.patch| 133 +
.../apmd/{apmd-3.2.2-14 = apmd}/libtool.patch | 0
.../apmd/{apmd-3.2.2-14 = apmd}/unlinux.patch | 0
.../apmd/{apmd_3.2.2-14.bb = apmd_3.2.2-15.bb}| 5 +-
9 files changed, 134 insertions(+), 4 deletions(-)
rename meta/recipes-bsp/apmd/{apmd-3.2.2-14 = apmd}/apmd.service (100%)
rename meta/recipes-bsp/apmd/{apmd-3.2.2-14 = apmd}/apmd_proxy (100%)
rename meta/recipes-bsp/apmd/{apmd-3.2.2-14 = apmd}/apmd_proxy.conf (100%)
rename meta/recipes-bsp/apmd/{apmd-3.2.2-14 = apmd}/default (100%)
rename meta/recipes-bsp/apmd/{apmd-3.2.2-14 = apmd}/init (100%)
create mode 100644 meta/recipes-bsp/apmd/apmd/legacy.patch
rename meta/recipes-bsp/apmd/{apmd-3.2.2-14 = apmd}/libtool.patch (100%)
rename meta/recipes-bsp/apmd/{apmd-3.2.2-14 = apmd}/unlinux.patch (100%)
rename meta/recipes-bsp/apmd/{apmd_3.2.2-14.bb = apmd_3.2.2-15.bb} (92%)
diff --git a/meta/recipes-bsp/apmd/apmd-3.2.2-14/apmd.service
b/meta/recipes-bsp/apmd/apmd/apmd.service
similarity index 100%
rename from meta/recipes-bsp/apmd/apmd-3.2.2-14/apmd.service
rename to meta/recipes-bsp/apmd/apmd/apmd.service
diff --git a/meta/recipes-bsp/apmd/apmd-3.2.2-14/apmd_proxy
b/meta/recipes-bsp/apmd/apmd/apmd_proxy
similarity index 100%
rename from meta/recipes-bsp/apmd/apmd-3.2.2-14/apmd_proxy
rename to meta/recipes-bsp/apmd/apmd/apmd_proxy
diff --git a/meta/recipes-bsp/apmd/apmd-3.2.2-14/apmd_proxy.conf
b/meta/recipes-bsp/apmd/apmd/apmd_proxy.conf
similarity index 100%
rename from meta/recipes-bsp/apmd/apmd-3.2.2-14/apmd_proxy.conf
rename to meta/recipes-bsp/apmd/apmd/apmd_proxy.conf
diff --git a/meta/recipes-bsp/apmd/apmd-3.2.2-14/default
b/meta/recipes-bsp/apmd/apmd/default
similarity index 100%
rename from meta/recipes-bsp/apmd/apmd-3.2.2-14/default
rename to meta/recipes-bsp/apmd/apmd/default
diff --git a/meta/recipes-bsp/apmd/apmd-3.2.2-14/init
b/meta/recipes-bsp/apmd/apmd/init
similarity index 100%
rename from meta/recipes-bsp/apmd/apmd-3.2.2-14/init
rename to meta/recipes-bsp/apmd/apmd/init
diff --git a/meta/recipes-bsp/apmd/apmd/legacy.patch
b/meta/recipes-bsp/apmd/apmd/legacy.patch
new file mode 100644
index 000..5db895e
--- /dev/null
+++ b/meta/recipes-bsp/apmd/apmd/legacy.patch
@@ -0,0 +1,133 @@
+From 3595933d221f0ba836917debc0776b8723972ec9 Mon Sep 17 00:00:00 2001
+From: Alexander Kanavin alex.kana...@gmail.com
+Date: Tue, 11 Aug 2015 17:40:50 +0300
+Subject: [PATCH 1/3] Patch with fixes provided by Debian.
+
+This patch is taken from
+ftp://ftp.debian.org/debian/pool/main/a/apmd/apmd_3.2.2-15.debian.tar.xz
+
+Upstream-Status: Inappropriate [upstream is dead]
+Signed-off-by: Alexander Kanavin alexander.kana...@linux.intel.com
+
+---
+ Makefile | 2 +-
+ apm.c| 3 ++-
+ apm.h| 9 +
+ apmd.c | 15 ---
+ 4 files changed, 20 insertions(+), 9 deletions(-)
+
+diff --git a/Makefile b/Makefile
+index bf346d9..92fc0fd 100644
+--- a/Makefile
b/Makefile
+@@ -43,7 +43,7 @@ DESTDIR=
+
+ CC=gcc
+ CFLAGS=-O -g
+-XTRACFLAGS=-Wall -pipe -I. -I/usr/src/linux/include \
++XTRACFLAGS=-Wall -pipe -I. -I/usr/src/linux/include -I/usr/X11R6/include \
+ -I/usr/src/linux-2.2/include -I /usr/src/linux-2.0/include \
+ -DVERSION=\$(VERSION)\ \
+ -DDEFAULT_PROXY_NAME=\$(PROXY_DIR)/apmd_proxy\
+diff --git a/apm.c b/apm.c
+index b21c057..0359b1c 100644
+--- a/apm.c
b/apm.c
+@@ -219,12 +219,13 @@ int main(int argc, char **argv)
+ }
+ }
+
+-
++#if 0
+ if (!(i.apm_flags APM_32_BIT_SUPPORT))
+ {
+ fprintf(stderr, 32-bit APM interface not supported\n);
+ exit(1);
+ }
++#endif
+
+ if (verbose (i.apm_flags 0x10))
+ printf(APM BIOS Power Management is currently disabled\n);
+diff --git a/apm.h b/apm.h
+index fb24dfd..824cc06 100644
+--- a/apm.h
b/apm.h
+@@ -20,6 +20,13 @@
+ * $Id: apm.h,v 1.7 1999/07/05 22:31:11 apenwarr Exp $
+ *
+ */
++#ifndef _APM_H
++#define _APM_H 1
++
++#ifndef __KERNEL_STRICT_NAMES
++#define __KERNEL_STRICT_NAMES
++#endif
++
+ #include linux/apm_bios.h
+ #include sys/types.h
+
+@@ -93,3 +100,5 @@ extern int apm_reject(int fd);
+ #else
+ #define apm_reject(fd) (-EINVAL)
+ #endif
++
++#endif
+diff --git a/apmd.c b/apmd.c
+index 49ed3a1..560f536 100644
+--- a/apmd.c
b/apmd.c
+@@ -343,7 +343,7 @@ static int call_proxy(apm_event_t event)
+ /* parent */
+
[OE-core] [PATCH 1/2] distrodata: Make self-contained.
Include by default all the files needed to perform checkpkg task.
These files are copied from meta-yocto because they refers recipes in
oe-core, the only missing file are maintainers.inc because it needs
consensus between OE-Core and Yocto project to define a common set of
maintainers.
[YOCTO #7895]
Signed-off-by: Aníbal Limón anibal.li...@linux.intel.com
---
meta/classes/distrodata.bbclass| 4 +
meta/conf/distro/include/distro_alias.inc | 536 +
meta/conf/distro/include/package_regex.inc | 265
meta/conf/distro/include/upstream_tracking.inc | 36 ++
4 files changed, 841 insertions(+)
create mode 100644 meta/conf/distro/include/distro_alias.inc
create mode 100644 meta/conf/distro/include/package_regex.inc
create mode 100644 meta/conf/distro/include/upstream_tracking.inc
diff --git a/meta/classes/distrodata.bbclass b/meta/classes/distrodata.bbclass
index 010cdc6..4168e43 100644
--- a/meta/classes/distrodata.bbclass
+++ b/meta/classes/distrodata.bbclass
@@ -1,4 +1,8 @@
include conf/distro/include/package_regex.inc
+include conf/distro/include/upstream_tracking.inc
+include conf/distro/include/distro_alias.inc
+include conf/distro/include/maintainers.inc
+
addhandler distro_eventhandler
distro_eventhandler[eventmask] = bb.event.BuildStarted
python distro_eventhandler() {
diff --git a/meta/conf/distro/include/distro_alias.inc
b/meta/conf/distro/include/distro_alias.inc
new file mode 100644
index 000..ec8570d
--- /dev/null
+++ b/meta/conf/distro/include/distro_alias.inc
@@ -0,0 +1,536 @@
+#
+# This is a list for tracking status of package relative to Major
+# distributions such as Fedora, Ubuntu, Debian, ... The package
+# name is the major distribution equivalent to the name used in oe-core
+#
+# The format is as a bitbake variable override for each recipe
+#
+# DISTRO_PN_ALIAS_pn-recipe name = Distro1=pkgname
Distro2=pkgname
+#
+# Please keep this list in alphabetical order.
+#
+DISTRO_PN_ALIAS_pn-aaina = Intel
+DISTRO_PN_ALIAS_pn-abiword-embedded = Fedora=abiword Ubuntu=abiword
+DISTRO_PN_ALIAS_pn-adt-installer = Intel
+DISTRO_PN_ALIAS_pn-alsa-state = OE-Core
+DISTRO_PN_ALIAS_pn-alsa-utils-alsaconf = OE-Core
+DISTRO_PN_ALIAS_pn-atk = Fedora=atk OpenSuSE=atk
+DISTRO_PN_ALIAS_pn-augeas = Ubuntu=libaugeas0 Debian=libaugeas0
+DISTRO_PN_ALIAS_pn-avahi-ui = Ubuntu=avahi-discover Debian=avahi-discover
+DISTRO_PN_ALIAS_pn-babeltrace = OSPDT
+DISTRO_PN_ALIAS_pn-bdwgc = OSPDT
+DISTRO_PN_ALIAS_pn-bigreqsproto = Meego=xorg-x11-proto-bigreqsproto
+DISTRO_PN_ALIAS_pn-bjam = OpenSuSE=boost-jam Debina=bjam
+DISTRO_PN_ALIAS_pn-blktool = Debian=blktool Mandriva=blktool
+DISTRO_PN_ALIAS_pn-bluez4 = Ubuntu=bluez Debian=bluez-utils
+DISTRO_PN_ALIAS_pn-bluez5 = Fedora=bluez Opensuse=bluez
+DISTRO_PN_ALIAS_pn-bluez-dtl1-workaround = OE-Core
+DISTRO_PN_ALIAS_pn-bootchart2 = Fedora=bootchart2 Opensuse=bootchart
+DISTRO_PN_ALIAS_pn-btrfs-tools = Debian=btrfs-tools Fedora=btrfs-progs
+DISTRO_PN_ALIAS_pn-build-appliance-image = OSPDT
+DISTRO_PN_ALIAS_pn-build-compare = Opensuse=build-compare
Fedora=build-compare
+DISTRO_PN_ALIAS_pn-builder = OE-Core
+DISTRO_PN_ALIAS_pn-buildtools-tarball = OE-Core
+DISTRO_PN_ALIAS_pn-calibrateproto = OSPDT
upstream=http://cgit.freedesktop.org/xorg/proto/calibrateproto;
+DISTRO_PN_ALIAS_pn-cdrtools = OpenSUSE=cdrtools OSPDT
+DISTRO_PN_ALIAS_pn-chkconfig-alternatives = Mandriva=chkconfig
Debian=chkconfig
+DISTRO_PN_ALIAS_pn-claws-plugin-gtkhtml2-viewer = Fedora=claws-mail-plugins
OpenSuSE=claws-mail-extra-plugins Debian=claws-mail-extra-plugins
+DISTRO_PN_ALIAS_pn-claws-plugin-maildir = Fedora=claws-mail-plugins
OpenSuSE=claws-mail-extra-plugins Debian=claws-mail-extra-plugins
+DISTRO_PN_ALIAS_pn-claws-plugin-mailmbox = Fedora=claws-mail-plugins
OpenSuSE=claws-mail-extra-plugins Debian=claws-mail-extra-plugins
+DISTRO_PN_ALIAS_pn-claws-plugin-rssyl = Fedora=claws-mail-plugins
OpenSuSE=claws-mail-extra-plugins Debian=claws-mail-extra-plugins
+DISTRO_PN_ALIAS_pn-clipboard-manager = OpenedHand
+DISTRO_PN_ALIAS_pn-clutter = Fedora=clutter OpenSuse=clutter
Ubuntu=clutter-1.0 Mandriva=clutter Debian=clutter
+DISTRO_PN_ALIAS_pn-clutter-1.8 = Fedora=clutter OpenSuse=clutter
Ubuntu=clutter-1.0 Mandriva=clutter Debian=clutter
+DISTRO_PN_ALIAS_pn-clutter-gst-1.0 = Debian=clutter-gst Ubuntu=clutter-gst
Fedora=clutter-gst
+DISTRO_PN_ALIAS_pn-clutter-gst-1.8 = Fedora=clutter-gst Debian=libclutter-gst
+DISTRO_PN_ALIAS_pn-clutter-gtk-1.0 = Debian=clutter-gtk Ubuntu=clutter-gtk
Fedora=clutter-gtk
+DISTRO_PN_ALIAS_pn-clutter-gtk-1.8 = Fedora=clutter-gtk OpenSuSE=clutter-gtk
Ubuntu=clutter-gtk-0.10 Mandriva=clutter-gtk Debian=clutter-gtk
+DISTRO_PN_ALIAS_pn-cogl-1.0 = Debian=cogl Ubuntu=cogl Fedora=cogl
+DISTRO_PN_ALIAS_pn-cogl = Fedora=cogl OpenSuse=cogl Ubuntu=cogl Mandriva=cogl
Debian=cogl
+DISTRO_PN_ALIAS_pn-compositeproto = Meego=xorg-x11-proto-compositeproto
+DISTRO_PN_ALIAS_pn-connman = Meego=connman
Re: [OE-core] [PATCH 1/2] distrodata: Make self-contained.
On 08/11/2015 07:41 PM, Aníbal Limón wrote: Include by default all the files needed to perform checkpkg task. These files are copied from meta-yocto because they refers recipes in oe-core, the only missing file are maintainers.inc because it needs consensus between OE-Core and Yocto project to define a common set of maintainers. Is there a PATCH 2/2? Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] distrodata: Make self-contained.
On 11 August 2015 at 17:49, Alexander Kanavin alexander.kana...@linux.intel.com wrote: Is there a PATCH 2/2? It's on the poky list as it is for meta-yocto. (both in MUT) Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCHv2] mc: Fix QA warning RDEPENDS of util-linux-libmount
On 11 August 2015 at 16:09, Aníbal Limón anibal.li...@linux.intel.com wrote: The QA warnings saya mc rdepends on util-linux-libmount, The warning is %s rdepends on %s, but it isn't a build dependency?. In this case, mc RDEPENDS on util-linux-libmount (via linking to libmount, and then the appropriate RDEPENDS being added automatically) but nothing in DEPENDS provides util-linux-libmount. In this case where we want libmount to be deterministically on, the solution is to add util-linux to DEPENDS (so util-linux-libmount is always available). Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]
On Tue, Aug 11, 2015 at 6:26 AM, Alexander Kanavin alexander.kana...@linux.intel.com wrote: On 08/10/2015 10:15 PM, Philip Balister wrote: This is perfectly fine with me. However, the subject has been whether the scope of *oe-core/poky* can be expanded without compromising What is Poky? Uhm... http://git.yoctoproject.org/cgit/cgit.cgi/poky/about/ can we freeze this thread please. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] distrodata: Make self-contained.
Right, i made a mistake here i sent another patch to the meta-yocto (poky) removing these items. alimon On 11/08/15 11:50, Burton, Ross wrote: On 11 August 2015 at 17:49, Alexander Kanavin alexander.kana...@linux.intel.com wrote: Is there a PATCH 2/2? It's on the poky list as it is for meta-yocto. (both in MUT) Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] build-appliance-image: use ext4 for rootfs
Changes due to IMAGES_FSTYPES vmdk and vdi now defaulting to ext4.
Switching Build Appliance to Ext4 will bring it more in-line with other BSPs.
[YOCTO #8096]
Signed-off-by: Juro Bystricky juro.bystri...@intel.com
---
meta/recipes-core/images/build-appliance-image_12.0.1.bb | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-core/images/build-appliance-image_12.0.1.bb
b/meta/recipes-core/images/build-appliance-image_12.0.1.bb
index 8e71b36..0a86ba4 100644
--- a/meta/recipes-core/images/build-appliance-image_12.0.1.bb
+++ b/meta/recipes-core/images/build-appliance-image_12.0.1.bb
@@ -14,7 +14,7 @@ IMAGE_FEATURES += x11-base package-management splash
IMAGE_ROOTFS_EXTRA_SPACE = 41943040
# Do a quiet boot with limited console messages
-APPEND += quiet
+APPEND += rootfstype=ext4 quiet
DEPENDS = zip-native
IMAGE_FSTYPES = vmdk
@@ -27,9 +27,9 @@ SRC_URI = git://git.yoctoproject.org/poky \
file://Yocto_Build_Appliance.vmxf \
-IMAGE_CMD_ext3_append () {
+IMAGE_CMD_ext4_append () {
# We don't need to reserve much space for root, 0.5% is more than enough
- tune2fs -m 0.5 ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ext3
+ tune2fs -m 0.5 ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ext4
}
fakeroot do_populate_poky_src () {
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/4] openssh: Upgrade 6.8p1 - 6.9p1
6.9p1 is primarily a bugfix release.
Signed-off-by: Jussi Kukkonen jussi.kukko...@intel.com
---
.../openssh/{openssh_6.8p1.bb = openssh_6.9p1.bb}| 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-connectivity/openssh/{openssh_6.8p1.bb =
openssh_6.9p1.bb} (97%)
diff --git a/meta/recipes-connectivity/openssh/openssh_6.8p1.bb
b/meta/recipes-connectivity/openssh/openssh_6.9p1.bb
similarity index 97%
rename from meta/recipes-connectivity/openssh/openssh_6.8p1.bb
rename to meta/recipes-connectivity/openssh/openssh_6.9p1.bb
index b00ef6f..3529c86 100644
--- a/meta/recipes-connectivity/openssh/openssh_6.8p1.bb
+++ b/meta/recipes-connectivity/openssh/openssh_6.9p1.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] = 08f72de6751acfbd0892b5f003922701
-SRC_URI[sha256sum] =
3ff64ce73ee124480b5bf767b9830d7d3c03bbcb6abe716b78f0192c37ce160e
+SRC_URI[md5sum] = 0b161c44fc31fbc6b76a6f8ae639f16f
+SRC_URI[sha256sum] =
6e074df538f357d440be6cf93dc581a21f22d39e236f217fcd8eacbb6c896cfe
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
[OE-core] [PATCH 4/4] librsvg: Upgrade 2.40.9 - 2.40.10
Rebase gtk-option.patch
Signed-off-by: Jussi Kukkonen jussi.kukko...@intel.com
---
meta/recipes-gnome/librsvg/librsvg/gtk-option.patch | 13 ++---
.../librsvg/{librsvg_2.40.9.bb = librsvg_2.40.10.bb} | 4 ++--
2 files changed, 8 insertions(+), 9 deletions(-)
rename meta/recipes-gnome/librsvg/{librsvg_2.40.9.bb = librsvg_2.40.10.bb}
(91%)
diff --git a/meta/recipes-gnome/librsvg/librsvg/gtk-option.patch
b/meta/recipes-gnome/librsvg/librsvg/gtk-option.patch
index 3835015..e6af481 100644
--- a/meta/recipes-gnome/librsvg/librsvg/gtk-option.patch
+++ b/meta/recipes-gnome/librsvg/librsvg/gtk-option.patch
@@ -1,6 +1,6 @@
-From 85d4af4451283f388e1e101ee4710bb19854154d Mon Sep 17 00:00:00 2001
+From 1c38d570b33f2b036d4fa47e929bb2b3264e38bd Mon Sep 17 00:00:00 2001
From: Jussi Kukkonen jussi.kukko...@intel.com
-Date: Fri, 10 Apr 2015 16:49:43 +0300
+Date: Tue, 11 Aug 2015 16:25:38 +0300
Subject: [PATCH] configure: add option to enable/disable use of GTK+
Distro packagers like predictability and automatically detected optional
@@ -11,8 +11,7 @@ Upstream-Status: Submitted
[https://bugzilla.gnome.org/show_bug.cgi?id=712693]
Signed-off-by: Ross Burton ross.bur...@intel.com
-
-Forward-ported to 2.40.9
+Forward-ported to 2.40.10
Signed-off-by: Jussi Kukkonen jussi.kukko...@intel.com
---
@@ -20,7 +19,7 @@ Signed-off-by: Jussi Kukkonen jussi.kukko...@intel.com
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/configure.ac b/configure.ac
-index e86c052..16b0e34 100644
+index bf77f3a..ca77de8 100644
--- a/configure.ac
+++ b/configure.ac
@@ -128,17 +128,22 @@ AC_CHECK_FUNCS(strtok_r)
@@ -55,8 +54,8 @@ index e86c052..16b0e34 100644
Build introspectable bindings: ${found_introspection}
Build Vala bindings:${enable_vala}
Build GdkPixbuf loader: ${enable_pixbuf_loader}
--GTK 3.0:${have_gtk_3}
-+GTK 3.0:${with_gtk3}
+-GTK+ $GTK3_REQUIRED or later: ${have_gtk_3}
++GTK+ $GTK3_REQUIRED or later: ${with_gtk_3}
Build miscellaenous tools: ${build_misc_tools}
--
diff --git a/meta/recipes-gnome/librsvg/librsvg_2.40.9.bb
b/meta/recipes-gnome/librsvg/librsvg_2.40.10.bb
similarity index 91%
rename from meta/recipes-gnome/librsvg/librsvg_2.40.9.bb
rename to meta/recipes-gnome/librsvg/librsvg_2.40.10.bb
index 9a14f29..0ac323e 100644
--- a/meta/recipes-gnome/librsvg/librsvg_2.40.9.bb
+++ b/meta/recipes-gnome/librsvg/librsvg_2.40.10.bb
@@ -16,8 +16,8 @@ GNOME_COMPRESS_TYPE = xz
SRC_URI += file://gtk-option.patch
-SRC_URI[archive.md5sum] = 31df15e3beaa8fbbf538ca3c52b400d2
-SRC_URI[archive.sha256sum] =
13964c5d35357552b47d365c34215eee0a63bf0e6059b689f048648c6bf5f43a
+SRC_URI[archive.md5sum] = fadebe2e799ab159169ee3198415ff85
+SRC_URI[archive.sha256sum] =
965c807438ce90b204e930ff80c92eba1606a2f6fd5ccfd09335c99896dd3479
EXTRA_OECONF = --disable-introspection --disable-vala
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/4] nfs-utils: Upgrade 1.3.1 - 1.3.2
Let --enable-tirpc be selected in configure by default: it is
a requirement for ipv6 support. This should not grow a typical
image size as libtirpc is a rpcbind dependency already.
Signed-off-by: Jussi Kukkonen jussi.kukko...@intel.com
---
.../nfs-utils/{nfs-utils_1.3.1.bb = nfs-utils_1.3.2.bb} | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
rename meta/recipes-connectivity/nfs-utils/{nfs-utils_1.3.1.bb =
nfs-utils_1.3.2.bb} (95%)
diff --git a/meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.1.bb
b/meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.2.bb
similarity index 95%
rename from meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.1.bb
rename to meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.2.bb
index 6da8509..59252c5 100644
--- a/meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.1.bb
+++ b/meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.2.bb
@@ -8,7 +8,7 @@ LICENSE = MIT GPLv2+ BSD
LIC_FILES_CHKSUM = file://COPYING;md5=95f3a93a5c3c7888de623b46ea085a84
# util-linux for libblkid
-DEPENDS = libcap libnfsidmap libevent util-linux sqlite3
+DEPENDS = libcap libnfsidmap libevent libtirpc util-linux sqlite3
RDEPENDS_${PN}-client = rpcbind bash
RDEPENDS_${PN} = ${PN}-client bash
RRECOMMENDS_${PN} = kernel-module-nfsd
@@ -33,8 +33,8 @@ SRC_URI =
${KERNELORG_MIRROR}/linux/utils/nfs-utils/${PV}/nfs-utils-${PV}.tar.x
file://nfs-utils-debianize-start-statd.patch \
-SRC_URI[md5sum] = 8de676b9ff34b8f9addc1d0800fabdf8
-SRC_URI[sha256sum] =
ff79d70b7b58b2c8f9b798c58721127e82bb96022adc04a5c4cb251630e696b8
+SRC_URI[md5sum] = 4cdffb2c7f7fd2bdceaba55ab1b881da
+SRC_URI[sha256sum] =
2966bb431c06e9ba35a54f48f89db03a5132bc2d8ed8084ac8ccb34e25a9b739
# Only kernel-module-nfsd is required here (but can be built-in) - the nfsd
module will
# pull in the remainder of the dependencies.
@@ -58,7 +58,6 @@ EXTRA_OECONF = --with-statduser=rpcuser \
--disable-nfsv41 \
--enable-uuid \
--disable-gss \
---disable-tirpc \
--disable-nfsdcltrack \
--with-statdpath=/var/lib/nfs/statd \
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/4] Upgrades: openssh, nss, nfs-utils, rsvg
The openssh upgrade adds a test that currently fails: that looks
like a failure in our test setup, I've filed a bug for that.
The following changes since commit a16e0b4014173af46ef80d643bb71055219b0dab:
bitbake: toaster: reduced amount of instance attributes (2015-08-10 13:58:02
-0700)
are available in the git repository at:
git://git.yoctoproject.org/poky-contrib jku/nss-openssh-nfsutils
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=jku/nss-openssh-nfsutils
Jussi Kukkonen (4):
openssh: Upgrade 6.8p1 - 6.9p1
nss: Upgrade 3.19.1 - 3.19.2
nfs-utils: Upgrade 1.3.1 - 1.3.2
librsvg: Upgrade 2.40.9 - 2.40.10
.../nfs-utils/{nfs-utils_1.3.1.bb = nfs-utils_1.3.2.bb}| 7 +++
.../openssh/{openssh_6.8p1.bb = openssh_6.9p1.bb} | 4 ++--
meta/recipes-gnome/librsvg/librsvg/gtk-option.patch | 13 ++---
.../librsvg/{librsvg_2.40.9.bb = librsvg_2.40.10.bb} | 4 ++--
meta/recipes-support/nss/{nss_3.19.1.bb = nss_3.19.2.bb} | 6 +++---
5 files changed, 16 insertions(+), 18 deletions(-)
rename meta/recipes-connectivity/nfs-utils/{nfs-utils_1.3.1.bb =
nfs-utils_1.3.2.bb} (95%)
rename meta/recipes-connectivity/openssh/{openssh_6.8p1.bb =
openssh_6.9p1.bb} (97%)
rename meta/recipes-gnome/librsvg/{librsvg_2.40.9.bb = librsvg_2.40.10.bb}
(91%)
rename meta/recipes-support/nss/{nss_3.19.1.bb = nss_3.19.2.bb} (97%)
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/2] Upgrade glibc to 2.22
On 11 August 2015 at 20:14, Khem Raj raj.k...@gmail.com wrote: On Wed, Aug 5, 2015 at 3:02 PM, Khem Raj raj.k...@gmail.com wrote: glibc 2.22 is now released. This has been tested on feature branch for months now as the release is out, therefore proposing it for master I have updated the pull request to fix the issue where PV was still using AUTOREV Where can this branch be found? Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/2] Upgrade glibc to 2.22
On Wed, Aug 5, 2015 at 3:02 PM, Khem Raj raj.k...@gmail.com wrote:
glibc 2.22 is now released. This has been tested on feature branch for months
now as the release is out, therefore proposing it for master
I have updated the pull request to fix the issue where PV was still
using AUTOREV
Khem Raj (2):
glibc: Upgrade 2.21 - 2.22
glibc: Package libmvec when built
meta/conf/distro/include/tcmode-default.inc|2 +-
...tive_2.21.bb = cross-localedef-native_2.22.bb} | 35 +-
...glibc-initial_2.21.bb = glibc-initial_2.22.bb} |0
.../{glibc-locale_2.21.bb = glibc-locale_2.22.bb} |0
.../{glibc-mtrace_2.21.bb = glibc-mtrace_2.22.bb} |0
meta/recipes-core/glibc/glibc-package.inc |2 +-
...glibc-scripts_2.21.bb = glibc-scripts_2.22.bb} |0
...ibc-Look-for-host-system-ld.so.cache-as-.patch} | 36 +-
...ibc-Fix-buffer-overrun-with-a-relocated-.patch} | 21 +-
...ibc-Raise-the-size-of-arrays-containing-.patch} | 126 +-
...tps-sourceware.org-ml-libc-ports-2007-12-.patch | 34 +
...00-e5500-e6500-603e-fsqrt-implementation.patch} | 222 +-
...-OECORE_KNOWN_INTERPRETER_NAMES-to-known-.patch | 33 +
...Fix-undefined-reference-to-__sqrt_finite.patch} | 192 +-
...rt-f-are-now-inline-functions-and-call-o.patch} | 270 +-
...ug-1443-which-explains-what-the-patch-do.patch} | 34 +-
...-libm-err-tab.pl-with-specific-dirs-in-S.patch} | 19 +-
...rt-f-are-now-inline-functions-and-call-o.patch} | 36 +-
...rsion-output-matching-grok-gold-s-output.patch} | 34 +-
...-configure.ac-handle-correctly-libc_cv_ro.patch | 42 +
...ibute.patch = 0014-Add-unused-attribute.patch} | 14 +-
...ng-SSE-also-make-sure-that-fpmath-is-not.patch} |6 +-
...hin-the-path-sets-wrong-config-variables.patch} | 30 +-
...timezone-re-written-tzselect-as-posix-sh.patch} | 31 +-
...-Cross-building-and-testing-instructions.patch} | 143 +-
...-Eglibc-option-group-infrastructure-to-g.patch} | 607 ++-
...20-eglibc-Help-bootstrap-cross-toolchain.patch} | 67 +-
...y-picked-from-http-www.eglibc.org-archiv.patch} | 30 +-
... 0022-eglibc-Clear-cache-lines-on-ppc8xx.patch} | 33 +-
...023-eglibc-Resolve-__fpscr_values-on-SH4.patch} | 48 +-
...rward-port-eglibc-options-groups-support.patch} | 5521
++--
...atch = 0025-eglibc-Install-PIC-archives.patch} | 44 +-
...bug_mask-is-controlled-by-__OPTION_EGLIB.patch} | 647 +--
...option-groups-Conditionally-exclude-c-tes.patch | 144 +
...81-resolv-nss_dns-dns-host.c-buffer-overf.patch | 43 -
.../glibc/Fix-__memcpy_chk-on-non-SSE2-CPUs.patch | 36 -
.../glibc/glibc/IO-acquire-lock-fix.patch | 17 -
.../glibc/glibc/add_resource_h_to_wait_h.patch | 20 -
.../glibc/glibc/elf-Makefile-fix-a-typo.patch | 36 -
.../glibc/glibc/fix-tibetian-locales.patch | 38 -
.../glibc/glibc/fix_am_rootsbindir.patch | 29 -
.../recipes-core/glibc/glibc/initgroups_keys.patch | 20 -
meta/recipes-core/glibc/glibc/makesyscall.patch| 51 -
.../glibc/glibc/mips-rld-map-check.patch | 27 -
.../glibc/glibc/multilib_readlib.patch | 19 -
.../glibc/{glibc_2.21.bb = glibc_2.22.bb} | 93 +-
46 files changed, 4661 insertions(+), 4271 deletions(-)
rename meta/recipes-core/glibc/{cross-localedef-native_2.21.bb =
cross-localedef-native_2.22.bb} (50%)
rename meta/recipes-core/glibc/{glibc-initial_2.21.bb =
glibc-initial_2.22.bb} (100%)
rename meta/recipes-core/glibc/{glibc-locale_2.21.bb =
glibc-locale_2.22.bb} (100%)
rename meta/recipes-core/glibc/{glibc-mtrace_2.21.bb =
glibc-mtrace_2.22.bb} (100%)
rename meta/recipes-core/glibc/{glibc-scripts_2.21.bb =
glibc-scripts_2.22.bb} (100%)
rename meta/recipes-core/glibc/glibc/{ld-search-order.patch =
0001-nativesdk-glibc-Look-for-host-system-ld.so.cache-as-.patch} (70%)
rename meta/recipes-core/glibc/glibc/{relocatable_sdk_fix_openpath.patch =
0002-nativesdk-glibc-Fix-buffer-overrun-with-a-relocated-.patch} (64%)
rename meta/recipes-core/glibc/glibc/{relocatable_sdk.patch =
0003-nativesdk-glibc-Raise-the-size-of-arrays-containing-.patch} (63%)
create mode 100644
meta/recipes-core/glibc/glibc/0004-Backport-https-sourceware.org-ml-libc-ports-2007-12-.patch
rename meta/recipes-core/glibc/glibc/{glibc.fix_sqrt2.patch =
0005-fsl-e500-e5500-e6500-603e-fsqrt-implementation.patch} (86%)
create mode 100644
meta/recipes-core/glibc/glibc/0006-readlib-Add-OECORE_KNOWN_INTERPRETER_NAMES-to-known-.patch
rename meta/recipes-core/glibc/glibc/{ppc-sqrt_finite.patch =
0007-ppc-sqrt-Fix-undefined-reference-to-__sqrt_finite.patch} (40%)
rename meta/recipes-core/glibc/glibc/{ppc_slow_ieee754_sqrt.patch =
0008-__ieee754_sqrt-f-are-now-inline-functions-and-call-o.patch} (53%)
rename meta/recipes-core/glibc/glibc/{0001-R_ARM_TLS_DTPOFF32.patch =
0009-Quote-from-bug-1443-which-explains-what-the-patch-do.patch} (78%)
Re: [OE-core] [PATCH 0/2] Upgrade glibc to 2.22
On Tue, Aug 11, 2015 at 12:26 PM, Burton, Ross ross.bur...@intel.com wrote: On 11 August 2015 at 20:14, Khem Raj raj.k...@gmail.com wrote: On Wed, Aug 5, 2015 at 3:02 PM, Khem Raj raj.k...@gmail.com wrote: glibc 2.22 is now released. This has been tested on feature branch for months now as the release is out, therefore proposing it for master I have updated the pull request to fix the issue where PV was still using AUTOREV Where can this branch be found? http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/for-master Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] IMAGES_FSTYPES: default to EXT4
The following IMAGES_FSTYPES defaulted to ext3:
vmdk, vdi, qcow2, live, iso, hddimg
This patch changes the default for those IMAGES_FSTYPES to
ext4 in order to bring the images more in line with other BSPs.
Besides improvements in performance and reliability ext4 provides
additional functionality as well (option to turn off the journaling,
dynamic resizing of VDI volumes etc.).
Signed-off-by: Juro Bystricky juro.bystri...@intel.com
---
meta/classes/bootimg.bbclass | 4 ++--
meta/classes/image-live.bbclass | 4 ++--
meta/classes/image-vm.bbclass| 8
meta/classes/image_types.bbclass | 2 +-
meta/lib/oe/image.py | 4 ++--
5 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/meta/classes/bootimg.bbclass b/meta/classes/bootimg.bbclass
index 5adcacc..ec9d0b7 100644
--- a/meta/classes/bootimg.bbclass
+++ b/meta/classes/bootimg.bbclass
@@ -296,8 +296,8 @@ python do_bootimg() {
bb.build.exec_func('build_iso', d)
}
-IMAGE_TYPEDEP_iso = ext3
-IMAGE_TYPEDEP_hddimg = ext3
+IMAGE_TYPEDEP_iso = ext4
+IMAGE_TYPEDEP_hddimg = ext4
IMAGE_TYPES_MASKED += iso hddimg
addtask bootimg before do_build
diff --git a/meta/classes/image-live.bbclass b/meta/classes/image-live.bbclass
index 52b6de7..fa7a131 100644
--- a/meta/classes/image-live.bbclass
+++ b/meta/classes/image-live.bbclass
@@ -7,12 +7,12 @@ SYSLINUX_TIMEOUT ?= 50
SYSLINUX_LABELS ?= boot install
LABELS_append = ${SYSLINUX_LABELS}
-ROOTFS ?= ${DEPLOY_DIR_IMAGE}/${IMAGE_BASENAME}-${MACHINE}.ext3
+ROOTFS ?= ${DEPLOY_DIR_IMAGE}/${IMAGE_BASENAME}-${MACHINE}.ext4
do_bootimg[depends] += ${INITRD_IMAGE}:do_rootfs
do_bootimg[depends] += ${PN}:do_rootfs
inherit bootimg
-IMAGE_TYPEDEP_live = ext3
+IMAGE_TYPEDEP_live = ext4
IMAGE_TYPES_MASKED += live
diff --git a/meta/classes/image-vm.bbclass b/meta/classes/image-vm.bbclass
index 28519c8..bc0503b 100644
--- a/meta/classes/image-vm.bbclass
+++ b/meta/classes/image-vm.bbclass
@@ -7,14 +7,14 @@ LABELS_append = ${SYSLINUX_LABELS}
# need to define the dependency and the ROOTFS for directdisk
do_bootdirectdisk[depends] += ${PN}:do_rootfs
-ROOTFS ?= ${DEPLOY_DIR_IMAGE}/${IMAGE_BASENAME}-${MACHINE}.ext3
+ROOTFS ?= ${DEPLOY_DIR_IMAGE}/${IMAGE_BASENAME}-${MACHINE}.ext4
# creating VM images relies on having a hddimg so ensure we inherit it here.
inherit boot-directdisk
-IMAGE_TYPEDEP_vmdk = ext3
-IMAGE_TYPEDEP_vdi = ext3
-IMAGE_TYPEDEP_qcow2 = ext3
+IMAGE_TYPEDEP_vmdk = ext4
+IMAGE_TYPEDEP_vdi = ext4
+IMAGE_TYPEDEP_qcow2 = ext4
IMAGE_TYPES_MASKED += vmdk vdi qcow2
create_vmdk_image () {
diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index cc789fc..35ceb7b 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -14,7 +14,7 @@ def imagetypes_getdepends(d):
ctypes = d.getVar('COMPRESSIONTYPES', True).split()
for type in (d.getVar('IMAGE_FSTYPES', True) or ).split():
if type in [vmdk, vdi, qcow2, live, iso, hddimg]:
-type = ext3
+type = ext4
basetype = type
for ctype in ctypes:
if type.endswith(. + ctype):
diff --git a/meta/lib/oe/image.py b/meta/lib/oe/image.py
index 40f6151..699c30f 100644
--- a/meta/lib/oe/image.py
+++ b/meta/lib/oe/image.py
@@ -76,8 +76,8 @@ class ImageDepGraph(object):
def _image_base_type(self, type):
ctypes = self.d.getVar('COMPRESSIONTYPES', True).split()
-if type in [vmdk, vdi, live, iso, hddimg]:
-type = ext3
+if type in [vmdk, vdi, qcow2, live, iso, hddimg]:
+type = ext4
basetype = type
for ctype in ctypes:
if type.endswith(. + ctype):
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/4] nss: Upgrade 3.19.1 - 3.19.2
This is a bug fix release.
Signed-off-by: Jussi Kukkonen jussi.kukko...@intel.com
---
meta/recipes-support/nss/{nss_3.19.1.bb = nss_3.19.2.bb} | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
rename meta/recipes-support/nss/{nss_3.19.1.bb = nss_3.19.2.bb} (97%)
diff --git a/meta/recipes-support/nss/nss_3.19.1.bb
b/meta/recipes-support/nss/nss_3.19.2.bb
similarity index 97%
rename from meta/recipes-support/nss/nss_3.19.1.bb
rename to meta/recipes-support/nss/nss_3.19.2.bb
index 66b9d60..23a4a1f 100644
--- a/meta/recipes-support/nss/nss_3.19.1.bb
+++ b/meta/recipes-support/nss/nss_3.19.2.bb
@@ -15,7 +15,7 @@ LIC_FILES_CHKSUM =
file://nss/COPYING;md5=3b1e88e1b9c0b5a4b2881d46cce06a18 \
file://nss/lib/freebl/mpi/doc/LICENSE-MPL;md5=5d425c8f3157dbf212db2ec53d9e5132
SRC_URI = \
-
http://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/NSS_3_19_1_RTM/src/${BP}.tar.gz
\
+
http://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/NSS_3_19_2_RTM/src/${BP}.tar.gz
\
file://nss-fix-support-cross-compiling.patch \
file://nss-no-rpath-for-cross-compiling.patch \
file://nss-fix-incorrect-shebang-of-perl.patch \
@@ -24,8 +24,8 @@ SRC_URI = \
file://signlibs.sh \
-SRC_URI[md5sum] = 68a9c01c987b9bd92066b4e0041f3e58
-SRC_URI[sha256sum] =
b7be709551ec13206d8e3e8c065b894fa981c11573115e9478fa051029c52fff
+SRC_URI[md5sum] = b02ffd1e8e8ef5f8512fa02d8ca9db3d
+SRC_URI[sha256sum] =
1306663e8f61d8449ad8cbcffab743a604dcd9f6f34232c210847c51dce2c9ae
inherit siteinfo
--
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/5] screen: Add version 4.3.1
On 10 August 2015 at 13:08, Jussi Kukkonen jussi.kukko...@intel.com wrote: * Preserve the old 4.0.3 version (GPLv2+) and add new 4.3.1 (GPLv3+) Is screen considered sufficiently core that we should maintain both GPLv2 and v3 recipes? I'm not convinced it is. * Remove unused debian patch from SRC_URI of 4.0.3, increase PR No need to increase PR. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/5] screen: Add version 4.3.1
On 08/11/2015 09:54 PM, Andre McCurdy wrote: On Tue, Aug 11, 2015 at 12:32 PM, Burton, Ross ross.bur...@intel.com wrote: On 10 August 2015 at 13:08, Jussi Kukkonen jussi.kukko...@intel.com wrote: * Preserve the old 4.0.3 version (GPLv2+) and add new 4.3.1 (GPLv3+) Is screen considered sufficiently core that we should maintain both GPLv2 and v3 recipes? I'm not convinced it is. Is it sufficiently core to be in oe-core at all? Or maybe it's time to replace screen with tmux? I use screen a lot. The question is, should the Yocto Project work towards converting screen users to tmux so we can drop it from or-core. Philip * Remove unused debian patch from SRC_URI of 4.0.3, increase PR No need to increase PR. Ross -- ___ 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/5] screen: Add version 4.3.1
On 11 August 2015 at 20:54, Andre McCurdy armccu...@gmail.com wrote: Is screen considered sufficiently core that we should maintain both GPLv2 and v3 recipes? I'm not convinced it is. Is it sufficiently core to be in oe-core at all? Or maybe it's time to replace screen with tmux? screen or tmux is a separate debate, but I believe that something like this is good for oe-core as it's so useful when all you have is a serial line to your board. I don't believe that's enough to keep two versions of screen in oe-core though. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]
On 11 August 2015 at 16:46, Khem Raj raj.k...@gmail.com wrote: can we freeze this thread please. Or more usefully, reboot it. Philip, you're turning into Koen! Alex, if someone on this list asks what Poky is, 99% of the time they're trolling. :) The original and unanswered question was should oe-core continue to maintain GPLv2 recipes where upstream has moved to GPLv3 or should those recipes move to a standalone layer with various implied questions: - If the v2 recipes move to a separate layer, who own/maintains/tests it? - Should there be v2 recipes for every recipe that has moved to v3, or only (as is now) the more-core recipes (currently YP tests that core-image-base builds without GPLv3, nothing else more complicated) - Should meta-gplv2 only contain recipes from oe-core, or all layers? If other layers decide to hold both v3 and v2 recipes (not that I'm aware any have), what makes oe-core special? I'm torn, Richard is torn. Neither of those are useful to forming a decision. Does anyone else have any *useful* feedback? Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/5] screen: Add version 4.3.1
On Tue, Aug 11, 2015 at 12:32 PM, Burton, Ross ross.bur...@intel.com wrote: On 10 August 2015 at 13:08, Jussi Kukkonen jussi.kukko...@intel.com wrote: * Preserve the old 4.0.3 version (GPLv2+) and add new 4.3.1 (GPLv3+) Is screen considered sufficiently core that we should maintain both GPLv2 and v3 recipes? I'm not convinced it is. Is it sufficiently core to be in oe-core at all? Or maybe it's time to replace screen with tmux? * Remove unused debian patch from SRC_URI of 4.0.3, increase PR No need to increase PR. Ross -- ___ 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/5] screen: Add version 4.3.1
On Tue, Aug 11, 2015 at 5:28 PM, Burton, Ross ross.bur...@intel.com wrote: On 11 August 2015 at 20:54, Andre McCurdy armccu...@gmail.com wrote: Is screen considered sufficiently core that we should maintain both GPLv2 and v3 recipes? I'm not convinced it is. Is it sufficiently core to be in oe-core at all? Or maybe it's time to replace screen with tmux? screen or tmux is a separate debate, but I believe that something like this is good for oe-core as it's so useful when all you have is a serial line to your board. I don't believe that's enough to keep two versions of screen in oe-core though. I vote it to go for meta-oe. If it was core, it would have been sent long time ago so lets add it for meta-oe and see how many people will ask for it to be promted. -- 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] meta-gplv2? [Was Re: parted_1.8.6.bb: add parted that not GPLv3]
On Tue, Aug 11, 2015 at 5:36 PM, Burton, Ross ross.bur...@intel.com wrote: On 11 August 2015 at 16:46, Khem Raj raj.k...@gmail.com wrote: can we freeze this thread please. Or more usefully, reboot it. Philip, you're turning into Koen! Alex, if someone on this list asks what Poky is, 99% of the time they're trolling. :) The original and unanswered question was should oe-core continue to maintain GPLv2 recipes where upstream has moved to GPLv3 or should those recipes move to a standalone layer with various implied questions: - If the v2 recipes move to a separate layer, who own/maintains/tests it? - Should there be v2 recipes for every recipe that has moved to v3, or only (as is now) the more-core recipes (currently YP tests that core-image-base builds without GPLv3, nothing else more complicated) - Should meta-gplv2 only contain recipes from oe-core, or all layers? If other layers decide to hold both v3 and v2 recipes (not that I'm aware any have), what makes oe-core special? I'm torn, Richard is torn. Neither of those are useful to forming a decision. Does anyone else have any *useful* feedback? I think it is a matter of resource usage. Up to now, the GPLv2 maintenance has not been so hard and thus I would say for us to stay as is for now. We should revisit this for every release and review if it is time for split it or not. -- 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] [PATCH 1/1][RFC] devtool: Upgrade feature
From: Leonardo Sandoval leonardo.sandoval.gonza...@linux.intel.com
This is a new devtool's feature, which upgrades a recipe to a
particular version number. Code was taken from [1] where some modifications
were done (remove all email, buildhistory and statistics features,
use devtool logger instead of AUH logger) to adapt the devtool framework.
Once the upgrade is over, the new recipe will be located under the
devtool's workspace. This is a first approach to this feature; pending
tasks include:
1. The AUH [1] is used to rename and update the recipe. AUH is not
using the lib/oe/recipeutils library to do this work. AUH ported code should use
this library which is the one being used by the rest of the devtool features.
2. Currently, when 'update-recipe' is executed, the recipe under workspace
is updated with latest commits. The only task missing is to replace the new
recipe with the old one, commonly located under the meta layer.
3. When patches fail to apply, follow the PATCHRESOLVE behavior instead of
just failing.
4. Patches most of the time do not apply correctly on the new recipe version,
so include a command line option to indicate the system not to apply these,
so it can be applied manually later on.
[1] http://git.yoctoproject.org/cgit/cgit.cgi/auto-upgrade-helper/
[YOCTO #7642]
Signed-off-by: Leonardo Sandoval leonardo.sandoval.gonza...@linux.intel.com
---
scripts/lib/devtool/auto-upgrade-helper/bitbake.py | 102 +
scripts/lib/devtool/auto-upgrade-helper/errors.py | 87 +
scripts/lib/devtool/auto-upgrade-helper/git.py | 101 +
.../lib/devtool/auto-upgrade-helper/gitrecipe.py | 98 +
scripts/lib/devtool/auto-upgrade-helper/recipe.py | 428 +
.../lib/devtool/auto-upgrade-helper/svnrecipe.py | 28 ++
.../devtool/auto-upgrade-helper/upgradehelper.py | 150
scripts/lib/devtool/standard.py| 119 ++
8 files changed, 1113 insertions(+)
create mode 100644 scripts/lib/devtool/auto-upgrade-helper/bitbake.py
create mode 100644 scripts/lib/devtool/auto-upgrade-helper/errors.py
create mode 100644 scripts/lib/devtool/auto-upgrade-helper/git.py
create mode 100644 scripts/lib/devtool/auto-upgrade-helper/gitrecipe.py
create mode 100644 scripts/lib/devtool/auto-upgrade-helper/recipe.py
create mode 100644 scripts/lib/devtool/auto-upgrade-helper/svnrecipe.py
create mode 100755 scripts/lib/devtool/auto-upgrade-helper/upgradehelper.py
diff --git a/scripts/lib/devtool/auto-upgrade-helper/bitbake.py
b/scripts/lib/devtool/auto-upgrade-helper/bitbake.py
new file mode 100644
index 000..5404807
--- /dev/null
+++ b/scripts/lib/devtool/auto-upgrade-helper/bitbake.py
@@ -0,0 +1,102 @@
+#!/usr/bin/env python
+# vim: set ts=4 sw=4 et:
+#
+# Copyright (c) 2013 - 2014 Intel Corporation
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License
+# as published by the Free Software Foundation; either version 2
+# of the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
USA.
+#
+# AUTHORS
+# Laurentiu Palcu laurentiu.pa...@intel.com
+# Marius Avram marius.av...@intel.com
+#
+
+import os
+import logging
+import sys
+from errors import *
+
+logger = logging.getLogger('devtool')
+
+for path in os.environ[PATH].split(':'):
+if os.path.exists(path) and bitbake in os.listdir(path):
+sys.path.insert(0, os.path.join(path, ../lib))
+import bb
+
+class Bitbake(object):
+def __init__(self, build_dir):
+self.build_dir = build_dir
+self.log_dir = None
+super(Bitbake, self).__init__()
+
+def _cmd(self, recipe, options=None, env_var=None):
+cmd =
+if env_var is not None:
+cmd += env_var +
+cmd += bitbake
+if options is not None:
+cmd += options +
+
+cmd += recipe
+
+os.chdir(self.build_dir)
+
+try:
+stdout, stderr = bb.process.run(cmd)
+except bb.process.ExecutionError as e:
+logger.debug(%s returned:\n%s % (cmd, e.__str__()))
+
+if self.log_dir is not None and os.path.exists(self.log_dir):
+with open(os.path.join(self.log_dir, bitbake_log.txt), w+)
as log:
+log.write(e.stdout)
+
+raise Error(\' + cmd + \' failed, e.stdout, e.stderr)
+
+return stdout
+
+def set_log_dir(self, dir):
+self.log_dir = dir
+
+def get_stdout_log(self):
+return
[OE-core] [PATCH 0/1][RFC] devtool: Upgrade feature
From: Leonardo Sandoval leonardo.sandoval.gonza...@linux.intel.com There are several approaches when upgrading a recipe and on this patch it was decided to reused the code from the auto-upgrade-helper [1] and ported it into the devtool. There are several pending tasks as described in the patch's description. The progress of this feature is being track on [2]. [1] http://git.yoctoproject.org/cgit/cgit.cgi/auto-upgrade-helper/ [2] https://bugzilla.yoctoproject.org/show_bug.cgi?id=7642 The following changes since commit 48b5ea6782ec7e9ab8f9a28438ef0ededa5fe224: sanity.bbclass: check /bin/sh is dash or bash (2015-06-26 09:28:53 +0100) are available in the git repository at: git://git.yoctoproject.org/poky-contrib lsandov1/devtool-upgrade-functionality-7642 http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=lsandov1/devtool-upgrade-functionality-7642 Leonardo Sandoval (1): devtool: Upgrade feature scripts/lib/devtool/auto-upgrade-helper/bitbake.py | 102 + scripts/lib/devtool/auto-upgrade-helper/errors.py | 87 + scripts/lib/devtool/auto-upgrade-helper/git.py | 101 + .../lib/devtool/auto-upgrade-helper/gitrecipe.py | 98 + scripts/lib/devtool/auto-upgrade-helper/recipe.py | 428 + .../lib/devtool/auto-upgrade-helper/svnrecipe.py | 28 ++ .../devtool/auto-upgrade-helper/upgradehelper.py | 150 scripts/lib/devtool/standard.py| 119 ++ 8 files changed, 1113 insertions(+) create mode 100644 scripts/lib/devtool/auto-upgrade-helper/bitbake.py create mode 100644 scripts/lib/devtool/auto-upgrade-helper/errors.py create mode 100644 scripts/lib/devtool/auto-upgrade-helper/git.py create mode 100644 scripts/lib/devtool/auto-upgrade-helper/gitrecipe.py create mode 100644 scripts/lib/devtool/auto-upgrade-helper/recipe.py create mode 100644 scripts/lib/devtool/auto-upgrade-helper/svnrecipe.py create mode 100755 scripts/lib/devtool/auto-upgrade-helper/upgradehelper.py -- 1.8.4.5 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/5] screen: Add version 4.3.1
On Aug 11, 2015, at 1:37 PM, Otavio Salvador otavio.salva...@ossystems.com.br wrote: On Tue, Aug 11, 2015 at 5:28 PM, Burton, Ross ross.bur...@intel.com wrote: On 11 August 2015 at 20:54, Andre McCurdy armccu...@gmail.com wrote: Is screen considered sufficiently core that we should maintain both GPLv2 and v3 recipes? I'm not convinced it is. Is it sufficiently core to be in oe-core at all? Or maybe it's time to replace screen with tmux? screen or tmux is a separate debate, but I believe that something like this is good for oe-core as it's so useful when all you have is a serial line to your board. I don't believe that's enough to keep two versions of screen in oe-core though. I vote it to go for meta-oe. If it was core, it would have been sent long time ago so lets add it for meta-oe and see how many people will ask for it to be promted. yes this seems sensible to me. 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 19/21] epiphany: add a recipe from meta-gnome
On Aug 6, 2015, at 9:28 PM, Randy MacLeod randy.macl...@windriver.com wrote: Epiphany is replacing midori as the browser in oe-core recipe set and poky distribution. I just got caught up on oe-core and: https://www.mail-archive.com/yocto@yoctoproject.org/msg24522.html Please move the midori recipe and dependencies to meta-oe when this change is merged to oe-core. That would help anyone that needs to provide a transition warning. Of course it adds more cruft to meta-oe but that's a separate problem. just drop it. If someone needs it let them propose it to be included in other layers 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 2/2] base.bbclass/blacklist.bbclass: remove doc item when d.getVarFlags()
On 08/11/2015 08:45 PM, Otavio Salvador wrote:
On Thu, Jul 30, 2015 at 12:18 PM, Robert Yang liezhi.y...@windriver.com wrote:
The FOO[doc] is set in meta/conf/documentation.conf, we need remove it
from d.getVarFlags()'s return dict when it causes many loops.
Signed-off-by: Robert Yang liezhi.y...@windriver.com
It seems your commit log is incomplete or so as I couldn't understand
why this is need.
Also as Andre says, we ought to not break existing layer without a
very strong reason and if needed, changing documentation.conf instead
of this seems more adequate.
The code in base.bbclass is: (no remove PACKAGECONFIG[doc])
pkgconfigflags = d.getVarFlags(PACKAGECONFIG) or {}
if pkgconfigflags:
foo
And documentation.conf:
PACKAGECONFIG[doc] = This variable provides a means of enabling or disabling
features of a recipe on a per-recipe basis.
This will make if pkgconfigflags: always be true and cause many unneeded
loops since there is always PACKAGECONFIG[doc].
Remove PACKAGECONFIG[doc] or comment it sounds good to me.
// Robert
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] oprofile rebuilds for different MACHINES (sstate)
On Aug 11, 2015, at 8:26 PM, Denys Dmytriyenko de...@denix.org wrote:
So, I've been debugging the issue of oprofile rebuilding from one MACHINE to
another (causing PR issues, etc). I was able to trace it down to this line:
EXTRA_OECONF = --with-kernel=${STAGING_KERNEL_DIR} --without-x
ac_cv_prog_XSLTPROC=
And STAGING_KERNEL_DIR resolves to this:
STAGING_KERNEL_DIR = ${TMPDIR}/work-shared/${MACHINE}/kernel-source
Now, obviously, when MACHINE changes, sstate invalidates do_configure and
rebuilds oprofile.
The question is, what is the proper fix in this case - mark oprofile as
machine-specific with PACKAGE_ARCH = ${MACHINE_ARCH}, since it will be
configuring and building against (potentially) completely different kernel
tree. So, just mark it explicitly and be safe...
Or another option is to tell sstate to ignore changes to the above variables
with this simple line:
EXTRA_OECONF[vardepsexclude] = STAGING_KERNEL_DIR
This also does the trick, but I'm a bit worried there could be side-effects of
using oprofile against the wrong kernel... Any recommendations?
Using kernel staging dir is unnecessary here, oprofile’s configure is poking
for user space APIs
in linux/perf_event.h so linux-libc-headers dependency is enough. and use
—with-kernel=${STAGING_EXECPREFIXDIR}
instead of STAGING_KERNEL_DIR, that should fix it.
-Khem
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
[OE-core] [PATCH] kselftests: add 4.1 version of Kernel Selftest suite
From: Denys Dmytriyenko de...@ti.com
Signed-off-by: Denys Dmytriyenko de...@ti.com
---
meta/recipes-kernel/kselftests/kselftests_4.1.bb | 86
1 file changed, 86 insertions(+)
create mode 100644 meta/recipes-kernel/kselftests/kselftests_4.1.bb
diff --git a/meta/recipes-kernel/kselftests/kselftests_4.1.bb
b/meta/recipes-kernel/kselftests/kselftests_4.1.bb
new file mode 100644
index 000..d917fb5
--- /dev/null
+++ b/meta/recipes-kernel/kselftests/kselftests_4.1.bb
@@ -0,0 +1,86 @@
+SUMMARY = Linux Kernel Selftests
+LICENSE = GPLv2
+LIC_FILES_CHKSUM = file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7
+
+SRC_URI = https://www.kernel.org/pub/linux/kernel/v4.x/linux-${PV}.tar.xz;
+
+SRC_URI[md5sum] = fe9dc0f6729f36400ea81aa41d614c37
+SRC_URI[sha256sum] =
caf51f085aac1e1cea4d00dbbf3093ead07b551fc07b31b2a989c05f8ea72d9f
+
+S = ${WORKDIR}/linux-${PV}
+
+DEPENDS = virtual/kernel popt
+
+inherit kernel-arch
+
+TARGETS = cpu-hotplug efivarfs exec firmware ftrace kcmp memfd memory-hotplug
\
+ mount mqueue net ptrace size sysctl timers user vm
+
+# Arch specific tests
+TARGETS_append_x86 = breakpoints ipc x86
+TARGETS_append_x86-64 = breakpoints ipc x86
+TARGETS_append_powerpc = powerpc
+TARGETS_append_powerpc64 = powerpc
+
+EXTRA_OEMAKE += -C tools/testing/selftests TARGETS=${TARGETS}
INSTALL_PATH=${D}${bindir}/kselftests CC=${CC}
+
+# Their Makefiles are so sloppy, let's clean up a bit
+do_configure () {
+ sed s|^CC := .*||g -i ${S}/tools/testing/selftests/lib.mk
+ sed s|^CC = .*||g -i ${S}/tools/testing/selftests/timers/Makefile
+ sed s|^CC = .*||g -i ${S}/tools/testing/selftests/memfd/Makefile
+ sed s|^CC := .*||g -i
${S}/tools/testing/selftests/powerpc/switch_endian/Makefile
+ sed s|gcc|\$(CC)|g -i
${S}/tools/testing/selftests/breakpoints/Makefile
+ sed s|^LDFLAGS += -lrt -lpthread|LDLIBS += -lrt -lpthread|g -i
${S}/tools/testing/selftests/timers/Makefile
+}
+
+do_compile () {
+ oe_runmake
+}
+
+do_install () {
+ oe_runmake install
+}
+
+PACKAGE_BEFORE_PN = ${PN}-breakpoints ${PN}-cpu-hotplug ${PN}-efivarfs
${PN}-exec ${PN}-firmware ${PN}-ftrace \
+ ${PN}-ipc ${PN}-kcmp ${PN}-memfd ${PN}-memory-hotplug ${PN}-mount
${PN}-mqueue ${PN}-net ${PN}-powerpc \
+ ${PN}-ptrace ${PN}-size ${PN}-sysctl ${PN}-timers ${PN}-user ${PN}-vm
${PN}-x86
+
+FILES_${PN}-breakpoints = ${bindir}/kselftests/breakpoints
+FILES_${PN}-cpu-hotplug = ${bindir}/kselftests/cpu-hotplug
+FILES_${PN}-efivarfs = ${bindir}/kselftests/efivarfs
+FILES_${PN}-exec = ${bindir}/kselftests/exec
+FILES_${PN}-firmware = ${bindir}/kselftests/firmware
+FILES_${PN}-ftrace = ${bindir}/kselftests/ftrace
+FILES_${PN}-ipc = ${bindir}/kselftests/ipc
+FILES_${PN}-kcmp = ${bindir}/kselftests/kcmp
+FILES_${PN}-memfd = ${bindir}/kselftests/memfd
+FILES_${PN}-memory-hotplug = ${bindir}/kselftests/memory-hotplug
+FILES_${PN}-mount = ${bindir}/kselftests/mount
+FILES_${PN}-mqueue = ${bindir}/kselftests/mqueue
+FILES_${PN}-net = ${bindir}/kselftests/net
+FILES_${PN}-powerpc = ${bindir}/kselftests/powerpc
+FILES_${PN}-ptrace = ${bindir}/kselftests/ptrace
+FILES_${PN}-size = ${bindir}/kselftests/size
+FILES_${PN}-sysctl = ${bindir}/kselftests/sysctl
+FILES_${PN}-timers = ${bindir}/kselftests/timers
+FILES_${PN}-user = ${bindir}/kselftests/user
+FILES_${PN}-vm = ${bindir}/kselftests/vm
+FILES_${PN}-x86 = ${bindir}/kselftests/x86
+FILES_${PN}-dbg += ${bindir}/kselftests/*/.debug
+
+RDEPENDS_${PN}-cpu-hotplug += bash
+RDEPENDS_${PN}-efivarfs += bash
+RDEPENDS_${PN}-memory-hotplug += bash
+RDEPENDS_${PN}-net += bash
+RDEPENDS_${PN}-vm += bash
+RDEPENDS_${PN} += bash ${PN}-cpu-hotplug ${PN}-efivarfs ${PN}-exec
${PN}-firmware ${PN}-ftrace ${PN}-ipc \
+ ${PN}-kcmp ${PN}-memfd ${PN}-memory-hotplug ${PN}-mount ${PN}-mqueue
${PN}-net ${PN}-ptrace \
+ ${PN}-size ${PN}-sysctl ${PN}-timers ${PN}-user ${PN}-vm
+
+RDEPENDS_${PN}_append_x86 = ${PN}-breakpoints ${PN}-ipc ${PN}-x86
+RDEPENDS_${PN}_append_x86-64 = ${PN}-breakpoints ${PN}-ipc ${PN}-x86
+RDEPENDS_${PN}_append_powerpc = ${PN}-powerpc
+RDEPENDS_${PN}_append_powerpc64 = ${PN}-powerpc
+
+INSANE_SKIP_${PN} = already-stripped
--
2.2.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/4] nfs-utils: Upgrade 1.3.1 - 1.3.2
On Aug 11, 2015, at 12:13 PM, Jussi Kukkonen jussi.kukko...@intel.com wrote:
Let --enable-tirpc be selected in configure by default: it is
a requirement for ipv6 support. This should not grow a typical
image size as libtirpc is a rpcbind dependency already.
ideally you would want to define a PACKAGECONFIG for this which is
enabled/disabled with ipv6 distro feature knob.
Signed-off-by: Jussi Kukkonen jussi.kukko...@intel.com
---
.../nfs-utils/{nfs-utils_1.3.1.bb = nfs-utils_1.3.2.bb} | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
rename meta/recipes-connectivity/nfs-utils/{nfs-utils_1.3.1.bb =
nfs-utils_1.3.2.bb} (95%)
diff --git a/meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.1.bb
b/meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.2.bb
similarity index 95%
rename from meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.1.bb
rename to meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.2.bb
index 6da8509..59252c5 100644
--- a/meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.1.bb
+++ b/meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.2.bb
@@ -8,7 +8,7 @@ LICENSE = MIT GPLv2+ BSD
LIC_FILES_CHKSUM = file://COPYING;md5=95f3a93a5c3c7888de623b46ea085a84
# util-linux for libblkid
-DEPENDS = libcap libnfsidmap libevent util-linux sqlite3
+DEPENDS = libcap libnfsidmap libevent libtirpc util-linux sqlite3
RDEPENDS_${PN}-client = rpcbind bash
RDEPENDS_${PN} = ${PN}-client bash
RRECOMMENDS_${PN} = kernel-module-nfsd
@@ -33,8 +33,8 @@ SRC_URI =
${KERNELORG_MIRROR}/linux/utils/nfs-utils/${PV}/nfs-utils-${PV}.tar.x
file://nfs-utils-debianize-start-statd.patch \
-SRC_URI[md5sum] = 8de676b9ff34b8f9addc1d0800fabdf8
-SRC_URI[sha256sum] =
ff79d70b7b58b2c8f9b798c58721127e82bb96022adc04a5c4cb251630e696b8
+SRC_URI[md5sum] = 4cdffb2c7f7fd2bdceaba55ab1b881da
+SRC_URI[sha256sum] =
2966bb431c06e9ba35a54f48f89db03a5132bc2d8ed8084ac8ccb34e25a9b739
# Only kernel-module-nfsd is required here (but can be built-in) - the nfsd
module will
# pull in the remainder of the dependencies.
@@ -58,7 +58,6 @@ EXTRA_OECONF = --with-statduser=rpcuser \
--disable-nfsv41 \
--enable-uuid \
--disable-gss \
---disable-tirpc \
--disable-nfsdcltrack \
--with-statdpath=/var/lib/nfs/statd \
--
2.1.4
--
___
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 19/21] epiphany: add a recipe from meta-gnome
On 2015-08-07 08:44 AM, Alexander Kanavin wrote: On 08/07/2015 07:28 AM, Randy MacLeod wrote: Epiphany is replacing midori as the browser in oe-core recipe set and poky distribution. I just got caught up on oe-core and: https://www.mail-archive.com/yocto@yoctoproject.org/msg24522.html Please move the midori recipe and dependencies to meta-oe when this change is merged to oe-core. That would help anyone that needs to provide a transition warning. Of course it adds more cruft to meta-oe but that's a separate problem. Midori depends on an ancient, no longer maintained Webkit1 implementation with known security issues [1]. Adding it to meta-oe requires that: a) webkit-gtk is at least updated to the latest version of the no longer maintained Webkit1 implementation (1.8.3 - 2.4.9) 2) that version is patched with every fix that other distributions have done, including [1] I can do this, but at the expense of updating other packages in oe-core that need updating before we hit a stabilization milestone. Do you specifically know someone who needs such an extra-cushioned transition? Thanks for the summary. After considering the situation, I agree that it's not worth the effort to add midori to meta-oe. ../Randy Alex [1] https://bugzilla.redhat.com/show_bug.cgi?id=1182623 -- # 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
[OE-core] oprofile rebuilds for different MACHINES (sstate)
So, I've been debugging the issue of oprofile rebuilding from one MACHINE to
another (causing PR issues, etc). I was able to trace it down to this line:
EXTRA_OECONF = --with-kernel=${STAGING_KERNEL_DIR} --without-x
ac_cv_prog_XSLTPROC=
And STAGING_KERNEL_DIR resolves to this:
STAGING_KERNEL_DIR = ${TMPDIR}/work-shared/${MACHINE}/kernel-source
Now, obviously, when MACHINE changes, sstate invalidates do_configure and
rebuilds oprofile.
The question is, what is the proper fix in this case - mark oprofile as
machine-specific with PACKAGE_ARCH = ${MACHINE_ARCH}, since it will be
configuring and building against (potentially) completely different kernel
tree. So, just mark it explicitly and be safe...
Or another option is to tell sstate to ignore changes to the above variables
with this simple line:
EXTRA_OECONF[vardepsexclude] = STAGING_KERNEL_DIR
This also does the trick, but I'm a bit worried there could be side-effects of
using oprofile against the wrong kernel... Any recommendations?
--
Denys
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] kselftests: add 4.1 version of Kernel Selftest suite
On Tue, Aug 11, 2015 at 8:33 PM, Denys Dmytriyenko de...@denix.org wrote: From: Denys Dmytriyenko de...@ti.com Signed-off-by: Denys Dmytriyenko de...@ti.com This should make use of dynamic package split so it is easier to maintain. -- 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
