Re: [OE-core] [PATCH v2] util-linux: create util-linux-runuser package

On Tuesday 10 November 2015 15:48:59 Mike Looijmans wrote: > On 10-11-15 09:50, Ioan-Adrian Ratiu wrote: > > Split runuser into its own package (previously provided by util-linux). > > Since runuser is compiled only when DISTRO_FEATURES includes pam, > > the creation of util-linux-runuser is also

Re: [OE-core] [PATCH 5/5] useradd-staticids.bbclass: Read passwd/group files before parsing

On 11/10/15 9:54 AM, Peter Kjellerstedt wrote: >> -Original Message- >> From: Mark Hatle [mailto:mark.ha...@windriver.com] >> Sent: den 6 november 2015 21:14 >> To: Peter Kjellerstedt >> Cc: openembedded-core@lists.openembedded.org >> Subject: Re: [PATCH 5/5] useradd-staticids.bbclass:

Re: [OE-core] [RFC] Remove vala from oe-core

On Tuesday 10 November 2015 16:30:05 Alexander Kanavin wrote: > On 11/10/2015 04:22 PM, Jussi Kukkonen wrote: > > There's currently no software built with vala in oe-core. That's not > > great for vala (as it's not getting the automated testing that high > > quality maintenance would require) and

Re: [OE-core] [RFC] Remove vala from oe-core

On Tue, Nov 10, 2015 at 04:22:07PM +0200, Jussi Kukkonen wrote: > Hi all, > > There's currently no software built with vala in oe-core. That's not great > for vala (as it's not getting the automated testing that high quality > maintenance would require) and it's not great for oe-core (as

Re: [OE-core] [RFC] Remove vala from oe-core

On Tuesday 10 November 2015 17:06:14 Alexander Kanavin wrote: > On 11/10/2015 04:50 PM, Paul Eggleton wrote: > > When considering whether something belongs in OE-Core, typically we apply > > the following criteria (not that this is really formalised, but based on > > our history): > > > > 1) Is

Re: [OE-core] [RFC] Remove vala from oe-core

On 10 November 2015 at 15:06, Alexander Kanavin < alexander.kana...@linux.intel.com> wrote: > I should clarify: there might be Vala software out there that someone > would want to run in an embedded context. And that software might require > Vala bindings for libraries that are in oe-core. If we

Re: [OE-core] [RFC] Remove vala from oe-core

On Tue, Nov 10, 2015 at 1:19 PM, Alexander Kanavin wrote: > On 11/10/2015 05:10 PM, Burton, Ross wrote: > >> I should clarify: there might be Vala software out there that >> someone would want to run in an embedded context. And that software >> might

[OE-core] [PATCH 0/1] Fix for intermittent license collection warning

This fix should also be backported to jethro. The following changes since commit e44ed8c18e395b9c055aefee113b90708e8a8a2f: build-appliance-image: Update to jethro head revision (2015-11-03 14:02:57 +) are available in the git repository at:

Re: [OE-core] [RFC] Remove vala from oe-core

On 11/10/2015 04:50 PM, Paul Eggleton wrote: When considering whether something belongs in OE-Core, typically we apply the following criteria (not that this is really formalised, but based on our history): 1) Is it something that a reasonable majority of people need in an embedded context? I

Re: [OE-core] [RFC] Remove vala from oe-core

On 11/10/2015 05:10 PM, Burton, Ross wrote: I should clarify: there might be Vala software out there that someone would want to run in an embedded context. And that software might require Vala bindings for libraries that are in oe-core. If we don't provide those bindings, then

Re: [OE-core] [RFC] Remove vala from oe-core

On Tue, Nov 10, 2015 at 2:25 PM, Andreas Müller wrote: > On Tue, Nov 10, 2015 at 4:39 PM, Otavio Salvador > wrote: >> On Tue, Nov 10, 2015 at 1:37 PM, Alexander Kanavin >> wrote: >>> On 11/10/2015

Re: [OE-core] [RFC] Remove vala from oe-core

On 11/10/2015 05:29 PM, Otavio Salvador wrote: PACKAGECONFIG alone is not sufficient; to build the bindings properly, the package also needs to inherit vala.bbclass:

Re: [OE-core] [RFC] Remove vala from oe-core

On Tue, Nov 10, 2015 at 4:39 PM, Otavio Salvador wrote: > On Tue, Nov 10, 2015 at 1:37 PM, Alexander Kanavin > wrote: >> On 11/10/2015 05:29 PM, Otavio Salvador wrote: >> PACKAGECONFIG alone is not sufficient; to build the

Re: [OE-core] [PATCH 00/29] Add gobject introspection support to oe-core

On 11/10/15 9:36 AM, Alexander Kanavin wrote: > On 11/10/2015 04:31 PM, Mark Hatle wrote: >> Is there a way that the qemu calls can be replaced by calls to an actual >> running >> board (via SSH perhaps) to get the necessary information? While inconvenient >> this might be a valid workaround. >

Re: [OE-core] [PATCHv2 6/6] license.bbclass: Create image license manifest

On 11/10/2015 04:42 AM, Paul Eggleton wrote: On Monday 09 November 2015 14:04:43 mariano.lo...@linux.intel.com wrote: From: Mariano Lopez This change adds the license_deployed_manifest function that will create the manifest for the packages deployed in the

Re: [OE-core] [PATCH 00/29] Add gobject introspection support to oe-core

On 11/10/2015 04:31 PM, Mark Hatle wrote: Is there a way that the qemu calls can be replaced by calls to an actual running board (via SSH perhaps) to get the necessary information? While inconvenient this might be a valid workaround. Theoretically, yes. Copy the sysroot and the build tree to

Re: [OE-core] [PATCH v2] util-linux: create util-linux-runuser package

On 10-11-15 09:50, Ioan-Adrian Ratiu wrote: Split runuser into its own package (previously provided by util-linux). Since runuser is compiled only when DISTRO_FEATURES includes pam, the creation of util-linux-runuser is also constrained by this. Signed-off-by: Ioan-Adrian Ratiu

[OE-core] [PATCH 1/1] classes/license: fix intermittent license collection warning

Fixes the following warning sometimes appearing during image builds: WARNING: The license listed ABC was not in the licenses collected for recipe xyz The files being looked for here, which runs during do_rootfs, are written out by the do_populate_lic task for each recipe. However, there was no

Re: [OE-core] [RFC] Remove vala from oe-core

On Tue, Nov 10, 2015 at 1:37 PM, Alexander Kanavin wrote: > On 11/10/2015 05:29 PM, Otavio Salvador wrote: > >>> PACKAGECONFIG alone is not sufficient; to build the bindings properly, >>> the >>> package also needs to inherit vala.bbclass: >>> >>> >>>

Re: [OE-core] [PATCH 5/5] useradd-staticids.bbclass: Read passwd/group files before parsing

> -Original Message- > From: Mark Hatle [mailto:mark.ha...@windriver.com] > Sent: den 6 november 2015 21:14 > To: Peter Kjellerstedt > Cc: openembedded-core@lists.openembedded.org > Subject: Re: [PATCH 5/5] useradd-staticids.bbclass: Read passwd/group > files before parsing > > On 11/6/15

Re: [OE-core] [PATCH 00/29] Add gobject introspection support to oe-core

On 10 November 2015 at 16:39, Mark Hatle wrote: > Let me rephrase. Instead of calling out to qemu (or a real target) for a > gobject and result. Can the result be cached (like we do with the > config-site > info?) This would allow me to run say a MIPS64 n64 gobject

[OE-core] [PATCH] linux-firmware: package Broadcom BCM4339 firmware

Signed-off-by: Tzu-Jung Lee diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb index 4939ca6..615fbdb 100644 --- a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb +++

[OE-core] [oe-core][PATCH 1/1] libsecret: add dependency on intltool-native

intltoolize is needed by configure. Signed-off-by: Joe Slater --- meta/recipes-gnome/libsecret/libsecret_0.18.2.bb |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-gnome/libsecret/libsecret_0.18.2.bb

Re: [OE-core] [Fido] readline CVE-2014-2524

On 06/11/15 01:36, akuster808 wrote: please backport from Master 9a02df0e932106bcb3dda0a7a2eb1113719fb4ee readline: actually apply readline63-003 (aka CVE-2014-2524) Thanks, I've queued this in my joshuagl/fido-next branch. Regards, Joshua -- ___

Re: [OE-core] [PATCH 00/29] Add gobject introspection support to oe-core

On 11/10/15 5:40 PM, Burton, Ross wrote: > > On 10 November 2015 at 23:10, Phil Blundell > > wrote: > > Why does gobject-introspection (presumably giscanner, right?) need to > run binaries on the target at all? I thought it operated mostly on the

Re: [OE-core] [PATCH] util-linux: create util-linux-runuser package

On Mon, 9 Nov 2015 15:15:54 -0600 Richard Tollerton wrote: > Ioan-Adrian Ratiu writes: > > > RDEPENDS_${PN} = "util-linux-umount util-linux-swaponoff > > util-linux-losetup util-linux-sulogin" > > RRECOMMENDS_${PN} = "util-linux-fdisk

Re: [OE-core] [oe] kernel.bbclass: Fix do_shared_workdir task ordering

> Am 14.10.2015 um 21:48 schrieb Bruce Ashfield : > > On Wed, Oct 14, 2015 at 3:30 PM, S. Lockwood-Childs wrote: >> http://patchwork.openembedded.org/patch/99875/ >> >> Apparently this patch is still not in master, and I just ran across the >>

Re: [OE-core] [PATCH] glew: set correct version in our configuration

On 10 November 2015 at 00:12, Andreas Müller wrote: > -+AC_INIT([glew], [1.9.0], [BUG-REPORT-ADDRESS]) > ++AC_INIT([glew], [1.12.0], [BUG-REPORT-ADDRESS]) > This is going to get tedious quickly, can we have a patch postfunc to sed in the right version at build

[OE-core] [PATCH v2] util-linux: create util-linux-runuser package

Split runuser into its own package (previously provided by util-linux). Since runuser is compiled only when DISTRO_FEATURES includes pam, the creation of util-linux-runuser is also constrained by this. Signed-off-by: Ioan-Adrian Ratiu ---

[OE-core] [PATCH][master][jethro][fido][dizzy] image.bbclass: don't add BUILDNAME to do_rootfs vardeps

* it was explicitly excluded in rootfs_*.bbclass which doesn't use this variable anymore, so we can drop it there, but I don't understand why it was added explicitly in image.bbclass, we don't want image to rebuild just because timestamp is different. * causes following ERROR when bitbake -S

Re: [OE-core] [PATCH][master][jethro][fido][dizzy] image.bbclass: don't add BUILDNAME to do_rootfs vardeps

On Tue, Nov 10, 2015 at 09:58:11AM +0100, Martin Jansa wrote: > * it was explicitly excluded in rootfs_*.bbclass which doesn't use this > variable anymore, so we can drop it there, but I don't understand why > it was added explicitly in image.bbclass, we don't want image to > rebuild just

Re: [OE-core] [PATCHv2 5/6] license.bbclass: Add function get_deployed_files

On Monday 09 November 2015 14:04:42 mariano.lo...@linux.intel.com wrote: > From: Mariano Lopez > > This function will get the files that were deployed in > the image using the sstate-control manifest file. This > will give a better view of what was deployed in the

[OE-core] [PATCH][dizzy] image.bbclass: don't let do_rootfs depend on BUILDNAME

From: Chen Qi BUILDNAME is set by cooker as a string of current time. Letting do_rootfs task depend on this variable gets us no benefit. Besides, letting do_rootfs task depend on this variable will cause us trouble when executing `bitbake -S none core-image-minimal'. With

[OE-core] [PATCH] rootfs_*.bbclass: don't add BUILDNAME to do_rootfs vardepsexclude

* rootfs_*.bbclass doesn't use this variable anymore, so we can drop it Signed-off-by: Martin Jansa --- meta/classes/rootfs_deb.bbclass | 1 - meta/classes/rootfs_ipk.bbclass | 1 - meta/classes/rootfs_rpm.bbclass | 1 - 3 files changed, 3 deletions(-) diff --git

Re: [OE-core] [PATCH 1/1] Update libusb1 from 1.0.19 to 1.0.20

> Am 08.11.2015 um 00:31 schrieb Burton, Ross : > > > On 7 November 2015 at 10:36, Jens Rehsack wrote: > I look into it and send a v2, if necessary > > Thanks Jens! Since I couldn't reproduce it (on a 12-core machine using different -j settings), I

Re: [OE-core] [PATCH] e2fsprogs: fix the ptest

On 10 November 2015 at 04:56, wrote: > ++goal = last_goal - 1 >= 0; last_goal - 1, 0; > Did this get mangled in application? That looks like it sets last_goal to 0 or 1 and then evaluates expressions with no side-effects or assignments. Ross --

Re: [OE-core] [PATCH] e2fsprogs: fix the ptest

On 10 November 2015 at 04:56, wrote: > ++goal = last_goal - 1 >= 0; last_goal - 1, 0; > I'm guessing this was a ternary expression gone wrong and the intended code was: goal = last_goal -1 >= 0 ? last_goal - 1 : 0; This patch makes a *massive*

Re: [OE-core] [PATCHv2 2/6] license.bbclass: Added get_boot_dependencies function

Hi Mariano, On Monday 09 November 2015 14:04:39 mariano.lo...@linux.intel.com wrote: > From: Mariano Lopez > > This function gets the dependencies from the classes that > create a boot image, this is required because sometimes > the bootloader dependecy is in

Re: [OE-core] [PATCHv2 6/6] license.bbclass: Create image license manifest

On Monday 09 November 2015 14:04:43 mariano.lo...@linux.intel.com wrote: > From: Mariano Lopez > > This change adds the license_deployed_manifest function > that will create the manifest for the packages deployed > in the image but not installed in rootfs. Again,

Re: [OE-core] [PATCH] glew: set correct version in our configuration

On Tue, Nov 10, 2015 at 11:36 AM, Burton, Ross wrote: > > On 10 November 2015 at 00:12, Andreas Müller > wrote: >> >> -+AC_INIT([glew], [1.9.0], [BUG-REPORT-ADDRESS]) >> ++AC_INIT([glew], [1.12.0], [BUG-REPORT-ADDRESS]) > > > This is going to

Re: [OE-core] [PATCH] u-boot: Update to 2015.10 release

On Mon, Nov 9, 2015 at 9:25 PM, Tom Rini wrote: > On Mon, Nov 09, 2015 at 08:04:31PM -0200, Otavio Salvador wrote: >> On Mon, Nov 9, 2015 at 7:47 PM, Tom Rini wrote: >> > On Mon, Nov 09, 2015 at 07:11:37PM -0200, Otavio Salvador wrote: >> >> On Mon, Nov 9,

[OE-core] [PATCH v2] u-boot: Update to 2015.10 release

The U-Boot 2015.10 has been released at October 20th 2015. This also removes the GCC workaround, for the inline behavior, as this version properlu supports the GCC 5.2 as compiler. Signed-off-by: Otavio Salvador --- Changes in v2: - Add patches from 2016.10 for GCC 5.2

[OE-core] [PATCH] lib/oe/copy_buildsystem: Don't expand BB_TASKDEPDATA

The value isn't a string so don't try and expand it. Signed-off-by: Richard Purdie --- meta/lib/oe/copy_buildsystem.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/lib/oe/copy_buildsystem.py b/meta/lib/oe/copy_buildsystem.py index

[OE-core] [PATCH] classes: Ensure pass setVar/setVarFlag strings, not integers

This doesn't cause any issues right now but it make sense to standardise on consistently using strings in the data store. Signed-off-by: Richard Purdie --- meta/classes/base.bbclass| 8 meta/classes/package_rpm.bbclass | 2 +-

[OE-core] [PATCH] insane: Don't depend on BB_TASKDEPDATA

The dependency data in BB_TASKDEPDATA is encoded into the sstate checksum in a much more reliable format. This dependency runs the risk of depending on the string representation of a dict which is a bad idea. Therefore remove the dependency. Signed-off-by: Richard Purdie

Re: [OE-core] [dizzy] [PATCH] python: Backport CVE-2013-1752 fix from upstream

On 11/10/2015 04:57 PM, Tudor Florea wrote: > There was not feedback on this. > Under the same CVE there lay actually many python vulnerabilities that are > still applicable for dizzy branch. > Among those only poplib module is covered > (python-2.7.3-CVE-2013-1752-poplib-fix.patch) > This

[OE-core] [PATCH 1/1] flex: fix test-bison-yylval and test-bison-yylloc failed

The tests in flex test-bison-yylval and test-bison-yylloc failed, so we backport a patch from upstream to fix it. Signed-off-by: Hongxu Jia --- ...fixes-Do-not-use-obsolete-bison-construct.patch | 81 ++ meta/recipes-devtools/flex/flex.inc

[OE-core] [PATCH 0/1] flex: fix test-bison-yylval and test-bison-yylloc failed

The following changes since commit fc45deac89ef63ca1c44e763c38ced7dfd72cbe1: build-appliance-image: Update to jethro head revision (2015-11-03 14:03:03 +) are available in the git repository at: git://git.pokylinux.org/poky-contrib hongxu/flex

Re: [OE-core] [RFC] Remove vala from oe-core

On 11/10/2015 04:22 PM, Jussi Kukkonen wrote: There's currently no software built with vala in oe-core. That's not great for vala (as it's not getting the automated testing that high quality maintenance would require) and it's not great for oe-core (as maintenance effort is better spent on

Re: [OE-core] [RFC] Remove vala from oe-core

On 11/10/2015 03:30 PM, Alexander Kanavin wrote: On 11/10/2015 04:22 PM, Jussi Kukkonen wrote: There's currently no software built with vala in oe-core. That's not great for vala (as it's not getting the automated testing that high quality maintenance would require) and it's not great for

Re: [OE-core] [PATCH 08/29] python-pygtk: remove the recipe

On Tuesday 10 November 2015 16:18:00 Jussi Kukkonen wrote: > On 10 November 2015 at 15:25, Alexander Kanavin < > > alexander.kana...@linux.intel.com> wrote: > > On 11/10/2015 03:13 PM, Jussi Kukkonen wrote: > >> Are the pygtk changes directly related to the introspection changes? If > >> not then

Re: [OE-core] [RFC] Remove vala from oe-core

On 11/10/2015 04:29 PM, Carlos Rafael Giani wrote: Doesn't vala rely on GObject introspection, which is unsupported in OE? I posted the patchset that adds the support for gobject introspection the other day. There is a bonus support for vala bindings in there as well. Alex --

Re: [OE-core] [PATCH 00/29] Add gobject introspection support to oe-core

On 11/9/15 8:50 AM, Alexander Kanavin wrote: > 1. Introduction > > This patchset adds support for gobject introspection to oe-core. > Gir files go to -dev packages, typelib files go to main packages > (they are packaged together with libraries that are > introspected). > > The work is based

[OE-core] [PATCHv3 1/2] oeqa/selftest/signing: New test for Signing packages in the package feeds.

[YOCTO # 8134] This test verifies features introduced in bug 8134. It requires as resources the files from meta-selftest/files/signing: For 'gpg --gen-key' the used input was: key: RSA key-size: 2048 key-valid: 0 realname: testuser email: testu...@email.com comment: nocomment passphrase: test123

[OE-core] [PATCHv3 2/2] oeqa/selftest/signing: Added new test for signing sstate.

[YOCTO #8182] Optional signing sstate archives and signature verification [YOCTO #8559] Signing sstate archives with custom dir for gpg keys Signed-off-by: Daniel Istrate --- meta/lib/oeqa/selftest/signing.py | 48 +++ 1

[OE-core] [PATCH 1/1] python3: Upgrade from 3.4.3 to 3.5

python3-native_3.4.3.bb -> python3-native_3.5.0.bb: - changed version - changed cheksum - no license change, just dates python3_3.4.3.bb -> python3_3.5.0.bb: - changed version - changed cheksum - no license change, just dates Rebased: - Manifest - 000-cross-compile.patch -

Re: [OE-core] [PATCH v2] u-boot: Update to 2015.10 release

On Tue, Nov 10, 2015 at 09:01:42AM -0200, Otavio Salvador wrote: > The U-Boot 2015.10 has been released at October 20th 2015. This also > removes the GCC workaround, for the inline behavior, as this version > properlu supports the GCC 5.2 as compiler. > > Signed-off-by: Otavio Salvador

Re: [OE-core] [PATCH 08/29] python-pygtk: remove the recipe

On 10 November 2015 at 15:25, Alexander Kanavin < alexander.kana...@linux.intel.com> wrote: > On 11/10/2015 03:13 PM, Jussi Kukkonen wrote: > >> Are the pygtk changes directly related to the introspection changes? If >> not then maybe they should happen in another patch set. >> > > They are;

[OE-core] [RFC] Remove vala from oe-core

Hi all, There's currently no software built with vala in oe-core. That's not great for vala (as it's not getting the automated testing that high quality maintenance would require) and it's not great for oe-core (as maintenance effort is better spent on components that _are_ used). Based on the

Re: [OE-core] [PATCH 00/29] Add gobject introspection support to oe-core

On Tue, 2015-11-10 at 10:39 -0600, Mark Hatle wrote: > Let me rephrase. Instead of calling out to qemu (or a real target) for a > gobject and result. Can the result be cached (like we do with the config-site > info?) This would allow me to run say a MIPS64 n64 gobject build, cache the > results

Re: [OE-core] [PATCH 00/29] Add gobject introspection support to oe-core

On 10 November 2015 at 23:10, Phil Blundell wrote: > Why does gobject-introspection (presumably giscanner, right?) need to > run binaries on the target at all? I thought it operated mostly on the > source code. > Same reason gtk-doc's scanner executes code: vast amounts of

Re: [OE-core] [PATCH 08/29] python-pygtk: remove the recipe

Are the pygtk changes directly related to the introspection changes? If not then maybe they should happen in another patch set. Jussi On 9 November 2015 at 16:50, Alexander Kanavin < alexander.kana...@linux.intel.com> wrote: > python-pygtk hasn't been updated in several years, is incompatible >

Re: [OE-core] [PATCH 08/29] python-pygtk: remove the recipe

On 11/10/2015 03:13 PM, Jussi Kukkonen wrote: Are the pygtk changes directly related to the introspection changes? If not then maybe they should happen in another patch set. They are; pygtk requires an old (2.x) non-introspection based version of pygobject, and the introspection patchset

Re: [OE-core] [PATCH] u-boot.inc: properly specify CC for EXTRA_OEMAKE

On Thu, Nov 05, 2015 at 03:23:48PM +0100, Carlos Rafael Giani wrote: > On 11/05/2015 03:22 PM, Otavio Salvador wrote: > >Hello Carlos, > > > >On Thu, Nov 5, 2015 at 11:16 AM, Carlos Rafael Giani > > wrote: > >>So, this is because of the TOOLCHAIN_OPTIONS ? > >>Also, what

Re: [OE-core] [PATCH 1/1] Update libusb1 from 1.0.19 to 1.0.20

On 10 November 2015 at 09:14, Jens Rehsack wrote: > Since I couldn't reproduce it (on a 12-core machine using different -j > settings), > I proved the Makefile.am and resulting Makefile - looks fine for me, > libusb-1.0.la > has among other things ...linux-netlink.lo as

Re: [OE-core] [PATCH] u-boot.inc: properly specify CC for EXTRA_OEMAKE

> On Nov 10, 2015, at 5:09 AM, Tom Rini wrote: > > On Thu, Nov 05, 2015 at 03:23:48PM +0100, Carlos Rafael Giani wrote: >> On 11/05/2015 03:22 PM, Otavio Salvador wrote: >>> Hello Carlos, >>> >>> On Thu, Nov 5, 2015 at 11:16 AM, Carlos Rafael Giani >>>