Re: [OE-core] [PATCH] binutils : enable production of EFI binaries on x86-64

2018-07-24 Thread Khem Raj
On Tue, Jul 24, 2018 at 8:16 PM Christopher Clark
 wrote:
>
> From: Christopher Clark 
>
> When MACHINE_FEATURES includes "efi" and target is x86-64,
> enable the linker to produce Portable Executables: EFI binaries.
>
> Supplies "--enable-targets=x86_64-pep" in EXTRA_OECONF.
>
> Enables building the EFI variant of the Xen hypervisor.
>
> Signed-off-by: Christopher Clark 
> ---
>  meta/recipes-devtools/binutils/binutils.inc | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/meta/recipes-devtools/binutils/binutils.inc 
> b/meta/recipes-devtools/binutils/binutils.inc
> index 37813dd..eedcc7e 100644
> --- a/meta/recipes-devtools/binutils/binutils.inc
> +++ b/meta/recipes-devtools/binutils/binutils.inc
> @@ -69,12 +69,15 @@ python do_package_prepend() {
>
>  B = "${S}/build.${HOST_SYS}.${TARGET_SYS}"
>
> +ENABLE_EFI_BINARIES_x86-64 = "--enable-targets=x86_64-pep"
> +



>  EXTRA_OECONF = "--program-prefix=${TARGET_PREFIX} \
>  --disable-werror \
>  --enable-deterministic-archives \
>  --enable-plugins \
>  ${LDGOLD} \
> -${@bb.utils.contains('DISTRO_FEATURES', 'multiarch', 
> '--enable-64-bit-bfd', '', d)}"
> +${@bb.utils.contains('DISTRO_FEATURES', 'multiarch', 
> '--enable-64-bit-bfd', '', d)} \
> +${@bb.utils.contains('MACHINE_FEATURES', 'efi', 
> '${ENABLE_EFI_BINARIES}', '', d)}"

I think we should avoid using machine features rather enable this
emulation unconditionally for efi enabled
targets, which for now are arm/x86/x86_64/aarch64

>
>  LDGOLD_class-native = ""
>  LDGOLD_class-crosssdk = ""
> --
> 2.7.4
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] binutils : enable production of EFI binaries on x86-64

2018-07-24 Thread Christopher Clark
From: Christopher Clark 

When MACHINE_FEATURES includes "efi" and target is x86-64,
enable the linker to produce Portable Executables: EFI binaries.

Supplies "--enable-targets=x86_64-pep" in EXTRA_OECONF.

Enables building the EFI variant of the Xen hypervisor.

Signed-off-by: Christopher Clark 
---
 meta/recipes-devtools/binutils/binutils.inc | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/binutils/binutils.inc 
b/meta/recipes-devtools/binutils/binutils.inc
index 37813dd..eedcc7e 100644
--- a/meta/recipes-devtools/binutils/binutils.inc
+++ b/meta/recipes-devtools/binutils/binutils.inc
@@ -69,12 +69,15 @@ python do_package_prepend() {
 
 B = "${S}/build.${HOST_SYS}.${TARGET_SYS}"
 
+ENABLE_EFI_BINARIES_x86-64 = "--enable-targets=x86_64-pep"
+
 EXTRA_OECONF = "--program-prefix=${TARGET_PREFIX} \
 --disable-werror \
 --enable-deterministic-archives \
 --enable-plugins \
 ${LDGOLD} \
-${@bb.utils.contains('DISTRO_FEATURES', 'multiarch', 
'--enable-64-bit-bfd', '', d)}"
+${@bb.utils.contains('DISTRO_FEATURES', 'multiarch', 
'--enable-64-bit-bfd', '', d)} \
+${@bb.utils.contains('MACHINE_FEATURES', 'efi', 
'${ENABLE_EFI_BINARIES}', '', d)}"
 
 LDGOLD_class-native = ""
 LDGOLD_class-crosssdk = ""
-- 
2.7.4

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


Re: [OE-core] [PATCH v3] udev-extraconf: Add systemd-mount to udev-extraconf/mount.sh

2018-07-24 Thread Hongzhi, Song

ping..

// Hongzhi


On 2018年07月13日 17:15, Hongzhi, Song wrote:

ping. Please.

-- Hongzhi


On 2018年07月03日 11:40, Hongzhi, Song wrote:

ping.

The patch fixes the real problem. Please review it.

//Hongzhi


On 2018年04月24日 04:20, Randy MacLeod wrote:

On 2018-04-22 11:37 PM, Hongzhi, Song wrote:

ping


Please be patient.

0e-core-2.5 rc1 is being tested now and only critical blocking fixes 
are being accepted.


Once the results of 2.5 tests are good, then commits such as this one
can be added to the master[-next] branch and then later 
cherry-picked back to 2.5.1

if needed.

Give people a few days (or more if things don't go well) to get 2.5 
out the door.


../Randy



// Hongzhi


On 2018年04月17日 15:03, Hongzhi.Song wrote:
Udev-extraconf works correctly with sysvinit in the aspect of 
automounting
block devices. But it has a serious problem in case of systemd. 
Block devices
automounted by udev is unaccessible to host space(out of udevd's 
private

namespace). For example, we cannot format those block devices.

e.g.
 root@qemux86:~# mkfs.ext4 /dev/sda1
 mke2fs 1.43.8 (1-Jan-2018)
 /dev/sda1 contains a ext4 file system
 last mounted on Tue Apr  3 06:22:41 2018
 Proceed anyway? (y,N) y
 /dev/sda1 is apparently in use by the system; will not make a 
filesystem here!


Other distributions has no such problem, because they use a series 
of rules to
manager block devices. Different types of block devices match 
different rules.
But udev-extraconf just use one rule, automount.rules, which 
results in this

problem.

The 'systemd-mount' command is recommended by the systemd 
community to solve such

problems.

This patch makes use of 'systemd-mount' to solve the above problem.

[YOCTO #12644]

Signed-off-by: Hongzhi.Song 
---
  meta/recipes-core/udev/udev-extraconf/mount.sh | 83 
--

  meta/recipes-core/udev/udev-extraconf_1.1.bb   |  3 +
  2 files changed, 69 insertions(+), 17 deletions(-)

diff --git a/meta/recipes-core/udev/udev-extraconf/mount.sh 
b/meta/recipes-core/udev/udev-extraconf/mount.sh

index d760328..067d4e2 100644
--- a/meta/recipes-core/udev/udev-extraconf/mount.sh
+++ b/meta/recipes-core/udev/udev-extraconf/mount.sh
@@ -4,10 +4,28 @@
  #
  # Attempt to mount any added block devices and umount any 
removed devices

  +BASE_INIT="`readlink "@base_sbindir@/init"`"
+INIT_SYSTEMD="@systemd_unitdir@/systemd"
+
+if [ "x$BASE_INIT" = "x$INIT_SYSTEMD" ];then
+    # systemd as init uses systemd-mount to mount block devices
+    MOUNT="/usr/bin/systemd-mount"
+    UMOUNT="/usr/bin/systemd-umount"
+
+    if [ -x $MOUNT ] && [ -x $UMOUNT ];
+    then
+    logger "Using systemd-mount to finish mount"
+    else
+    logger "Linux init is using systemd, so please install 
systemd-mount to finish mount"

+    exit 1
+    fi
+else
+    MOUNT="/bin/mount"
+    UMOUNT="/bin/umount"
+fi
  -MOUNT="/bin/mount"
  PMOUNT="/usr/bin/pmount"
-UMOUNT="/bin/umount"
+
  for line in `grep -h -v ^# /etc/udev/mount.blacklist 
/etc/udev/mount.blacklist.d/*`

  do
  if [ ` expr match "$DEVNAME" "$line" ` -gt 0 ];
@@ -17,7 +35,35 @@ do
  fi
  done
  -automount() {
+automount_systemd() {
+    name="`basename "$DEVNAME"`"
+
+    [ -d "/run/media/$name" ] || mkdir -p "/run/media/$name"
+
+    MOUNT="$MOUNT -o silent"
+
+    # If filesystemtype is vfat, change the ownership group to 
'disk', and

+    # grant it with  w/r/x permissions.
+    case $ID_FS_TYPE in
+    vfat|fat)
+    MOUNT="$MOUNT -o umask=007,gid=`awk -F':' '/^disk/{print 
$3}' /etc/group`"

+    ;;
+    # TODO
+    *)
+    ;;
+    esac
+
+    if ! $MOUNT --no-block -t auto $DEVNAME "/run/media/$name"
+    then
+    #logger "mount.sh/automount" "$MOUNT -t auto $DEVNAME 
\"/run/media/$name\" failed!"

+    rm_dir "/run/media/$name"
+    else
+    logger "mount.sh/automount" "Auto-mount of 
[/run/media/$name] successful"

+    touch "/tmp/.automount-$name"
+    fi
+}
+
+automount() {
  name="`basename "$DEVNAME"`"
    ! test -d "/run/media/$name" && mkdir -p "/run/media/$name"
@@ -26,7 +72,7 @@ automount() {
  then
  MOUNT="$MOUNT -o silent"
  fi
-
+
  # If filesystem type is vfat, change the ownership group to 
'disk', and

  # grant it with  w/r/x permissions.
  case $ID_FS_TYPE in
@@ -68,23 +114,26 @@ if [ "$ACTION" = "add" ] && [ -n "$DEVNAME" ] 
&& [ -n "$ID_FS_TYPE" -o "$media_t

  elif [ -x $MOUNT ]; then
  $MOUNT $DEVNAME 2> /dev/null
  fi
-
+
  # If the device isn't mounted at this point, it isn't
  # configured in fstab (note the root filesystem can show up as
  # /dev/root in /proc/mounts, so check the device number too)
-    if expr $MAJOR "*" 256 + $MINOR != `stat -c %d /`; then
-    grep -q "^$DEVNAME " /proc/mounts || automount
-    fi
+    if expr $MAJOR "*" 256 + $MINOR != `stat -c %d /`; then
+    if [ "`basename $MOUNT`" = "systemd-mount" ];then
+    grep -q "^$DEVNAME " 

[OE-core] aclocal question

2018-07-24 Thread Slater, Joseph
aclocal can generate rather large command lines (194000 characters) when 
calling autom4te to trace macros.  I think that this breaks at a little beyond 
the argument length I've mentioned.  I'm not familiar with this code but I 
think the bulk of the items could be piped into autom4te rather than the way it 
is done now.  This might not solve the problem but I wondered if anyone has 
looked at this issue.

Specifically, we have seen failures when building libvirt for a project with a 
long pathname.

Joe

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


Re: [OE-core] [meta-oe][PATCH] perl: native modules will not trigger build perl for target.

2018-07-24 Thread Andre McCurdy
On Tue, Jul 24, 2018 at 12:22 AM, Krzysztof Taborski
 wrote:
> Hello,
> Example recipe (recipe.bb for example):
> """
> LICENSE="CLOSED"
>
> RDEPENDS_${PN} = "perl-module-file-glob"
>
> BBCLASSEXTEND = "native nativesdk"
> do_install() {
> install -d ${D}/${bindir}
> echo "my perl script" > ${D}/${bindir}/recipe.pl
> }
> inherit perlnative
> ""
>
> When my patch is removed and I will call: "'bitbake recipe-native".
> Then I have dependency:
> recipe-native -> perl (target version)
> This is not correct, that native recipe has dependency to target recipe.

There are two parts to this issue.

First, the dependency between recipe-native and perl is certainly a
bug and your fix for that in the perl recipe looks good, ie setting

  PACKAGES_DYNAMIC += "^perl-module-.*(?
perl dependency will be gone, trying to build your recipe-native
should now generate a build failure - bitbake will correctly report
that nothing provides a package called "perl-module-file-glob-native".

The question is really how to fix that new build failure.

One approach (the approach you took - the second part of your patch)
is to update the perl-native recipe so that pretends to provide
packages named "perl-module-XXX-native".

The alternative approach is to explicitly set RDEPENDS for the -native
build of your recipe to over-ride the false dependency added by the
native class dependency renaming e.g.

  RDEPENDS_${PN}_class-native = "perl-native"

That second approach is basically what the autoconf recipe does to
solve a similar problem:

  
http://git.openembedded.org/openembedded-core/tree/meta/recipes-devtools/autoconf/autoconf.inc?h=sumo

As to which is the more "correct" approach, I'm not really sure.
Opinions welcome...

> When I called (bitbake recipe-native -g) I can find:
> "recipe-native" -> "perl"
> in recipe-depends.dot
>
> This was my original problem. Please correct me, if missed something.
>
> usage of += with an over-ride - I've just copied it from nativesdk
> over-ride, which was already in perl recipe.
>
>
> Best regards,
> Krzysztof Taborski
>
> 2018-07-23 19:23 GMT+02:00 Andre McCurdy :
>>
>> On Mon, Jul 23, 2018 at 5:57 AM, Krzysztof Taborski
>>  wrote:
>> > Change was already merged:
>> >
>> > http://cgit.openembedded.org/openembedded-core/commit/meta/recipes-devtools?id=7dd9772eca6df52db09b65537fdf689f1aa3fd8f
>> >
>> > Is your request still valid?
>>
>> Yes, although the change was merged, it's not clear that it was correct.
>>
>> Native recipes aren't split into packages, so there are no -native
>> versions of the perl modules. If you have a recipe which depends on
>> "perl-module-XXX-native" it's likely a bug in that recipe - not in
>> perl-native.
>>
>> What recipe did you find which depends on a -native version of a perl
>> module?
>>
>> > 2018-07-09 21:40 GMT+02:00 Andre McCurdy :
>> >>
>> >> On Wed, May 9, 2018 at 7:16 AM, taborskikrzysztof
>> >>  wrote:
>> >> > Can I request review?
>> >> >  Oryginalna wiadomość 
>> >> > Od: Krzysztof Taborski 
>> >> > Data: 08.05.2018 18:46 (GMT+01:00)
>> >> > Do: openembedded-core@lists.openembedded.org
>> >> > DW: Krzysztof Taborski 
>> >> > Temat: [meta-oe][PATCH] perl: native modules will not trigger build
>> >> > perl
>> >> > for
>> >> > target.
>> >> >
>> >> > Currently building perl-native modules triggers
>> >> > build perl for target due to PACKAGES_DYNAMIC regex.
>> >> >
>> >> > This commit will cause, that perl native modules will
>> >> > trigger perl-native build.
>> >>
>> >> Can you give an example of how to reproduce the problem?
>> >>
>> >> > Signed-off-by: Krzysztof Taborski 
>> >> > ---
>> >> > meta/recipes-devtools/perl/perl-native_5.24.1.bb | 2 ++
>> >> > meta/recipes-devtools/perl/perl_5.24.1.bb| 2 +-
>> >> > 2 files changed, 3 insertions(+), 1 deletion(-)
>> >> >
>> >> > diff --git a/meta/recipes-devtools/perl/perl-native_5.24.1.bb
>> >> > b/meta/recipes-devtools/perl/perl-native_5.24.1.bb
>> >> > index a9ab17d16c..71f45890b0 100644
>> >> > --- a/meta/recipes-devtools/perl/perl-native_5.24.1.bb
>> >> > +++ b/meta/recipes-devtools/perl/perl-native_5.24.1.bb
>> >> > @@ -135,3 +135,5 @@ EOF
>> >> >
>> >> > # Fix the path in sstate
>> >> > SSTATE_SCAN_FILES += "*.pm *.pod *.h *.pl *.sh"
>> >> > +PACKAGES_DYNAMIC_class-native += "^perl-module-.*native$"
>> >>
>> >> This usage of += with an over-ride is not correct.
>> >>
>> >> However, regardless of that, was this change actually needed?
>> >>
>> >> If you know of a -native recipe which depends on a
>> >> perl-module-XXX-native package then it's probably a bug in the -native
>> >> recipe. Having perl-native pretend to provide perl-module packages
>> >> probably isn't the right solution.
>> >>
>> >> > diff --git a/meta/recipes-devtools/perl/perl_5.24.1.bb
>> >> > b/meta/recipes-devtools/perl/perl_5.24.1.bb
>> >> > index 53a426289a..4c6a71082f 100644
>> >> > --- a/meta/recipes-devtools/perl/perl_5.24.1.bb
>> >> > +++ b/meta/recipes-devtools/perl/perl_5.24.1.bb
>> >> > @@ 

Re: [OE-core] [PATCH] lsof: Update SRC_URI

2018-07-24 Thread Randy MacLeod

On 07/24/2018 04:37 AM, Alexander Kanavin wrote:

Also, if an upgrade is undesirable for some reason, then such changes
need UPSTREAM_CHECK_URI, or we'll be missing new upstream releases.

Alex

2018-07-24 10:07 GMT+02:00 Burton, Ross :

Well for master if there's a new version then a better fix would be to
upgrade, 


Yes, there's a 4.91 as of March and a github repo in the works
according to the members-only list archive:


On  Fri Jun 22 09:55:59 EDT 2018, Victor Abell wrote:

  I am slowly making progress for the release of lsof to GitHUB
  from its Purdue Research Foundation copyright.  I have finally
  reached a person who works on open source distribution issues.
  He and I have had several discussions about lsof and its copyright
  and he now understands what needs to be done.  He has formulated
  a request to the senior IP officer for the release and we are waiting
  the response.

so for oe-core-2.6, we should use 4.91.



but we do need to make sure the previous releases are using
mirrors.


I expect that Ovidiu just forgot the branch prefix in his subject line.
Do you want him to resend for 2.5 and 2.4 ?

../Randy





On 24 July 2018 at 08:48, Ovidiu Panait  wrote:

lsof 4.89 archive has been moved to OLD directory and turned into tar.gz,
so update SRC_URI and checksums.

Signed-off-by: Ovidiu Panait 
---
  meta/recipes-extended/lsof/lsof_4.89.bb | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-extended/lsof/lsof_4.89.bb 
b/meta/recipes-extended/lsof/lsof_4.89.bb
index 14546db23c..b58b8281f9 100644
--- a/meta/recipes-extended/lsof/lsof_4.89.bb
+++ b/meta/recipes-extended/lsof/lsof_4.89.bb
@@ -11,12 +11,12 @@ LIC_FILES_CHKSUM = 
"file://00README;beginline=645;endline=679;md5=964df275d26429
  # https://people.freebsd.org/~abe/ ). http://www.mirrorservice.org seems to be
  # the most commonly used alternative.

-SRC_URI = 
"http://www.mirrorservice.org/sites/lsof.itap.purdue.edu/pub/tools/unix/lsof/lsof_${PV}.tar.bz2
 \
+SRC_URI = 
"http://www.mirrorservice.org/sites/lsof.itap.purdue.edu/pub/tools/unix/lsof/OLD/lsof_${PV}.tar.gz
 \
 file://lsof-remove-host-information.patch \
"

-SRC_URI[md5sum] = "1b9cd34f3fb86856a125abbf2be3a386"
-SRC_URI[sha256sum] = 
"81ac2fc5fdc944793baf41a14002b6deb5a29096b387744e28f8c30a360a3718"
+SRC_URI[md5sum] = "8afbaff3ee308edc130bdc5df0801c8f"
+SRC_URI[sha256sum] = 
"5d08da7ebe049c9d9a6472d6afb81aa5af54c4733a3f8822cbc22b57867633c9"

  LOCALSRC = "file://${WORKDIR}/lsof_${PV}/lsof_${PV}_src.tar"

--
2.17.1

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

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



--
# Randy MacLeod
# Wind River Linux
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] Setting include path in a recipe

2018-07-24 Thread Andre McCurdy
On Tue, Jul 24, 2018 at 6:52 AM, Adam Lee  wrote:
>
> How do I defined a custom include path for an autotools recipe?
>
> This may as well be explained somewhere in the reference manual, but I can't
> seem to find it.

Assuming you want to add a custom directory which is within sysroot:

CPPFLAGS += "-I=/usr/include/specialheaders"
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] Yocto Project Unassigned Bugs - Help Needed

2018-07-24 Thread Jolley, Stephen K
All,



The triage team meets weekly and does its best to handle the bugs reported into 
the bugzilla. The numbers of people attending that meeting have fallen, as have 
the number of people available to help fix bugs. One of the things we hear 
users report is they don't know how to help. We (the triage team) are therefore 
going to start reporting out the currently 327 unassigned bugs.



We're hoping people may be able to spare some time now and again to help out 
with these.



Bugs are split into two types, "true bugs" where things don't work as they 
should and "enhancements" which are features we'd want to add to the system.



There are also roughly three different "priority" classes right now, "2.6", 
"2.99" and "Future", the more pressing/urgent issues being in "2.6".



Please review this link and if a bug is something you would be able to help 
with either take ownership of the bug, or send me (stephen.k.jol...@intel.com) 
an e-mail with the bug number you would like and I will assign it to you 
(please make sure you have a bugzilla account).



The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage#Unassigned_Bugs


Thanks,

Stephen K. Jolley
Yocto Project Program Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
*Cell:(208) 244-4460
* Email: stephen.k.jol...@intel.com

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


[OE-core] Yocto Project Status WW30’18

2018-07-24 Thread Jolley, Stephen K
Current Dev Position: YP 2.6 M3.

Next Deadline: YP 2.6 M2 Release Target is July 27, 2018


SWAT Team Rotation:

· SWAT lead is currently: Amanda

· SWAT team rotation: Amanda -> Tracy on July 27, 2018

· SWAT team rotation: Tracy -> Armin on Aug. 3, 2018

· https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team


Key Status/Updates:

· YP 2.6 M2 is in QA. See 
https://wiki.yoctoproject.org/wiki/2.6_QA_Status.  It is 84% complete.

· YP 2.3.4 has been released.  This is the final release of the YP 2.3 
(pyro) series.

· YP 2.2.4 is out of QA and will release this week. This will be the 
final release of the YP 2.2 (morty) series.

· A new version of uninative-tarball will be released this week to fix 
issues sharing sstate from newer distros.

· Oe-selftest patches have merged however there are race issues in the 
test cases, particularly where the modify metadata as part of the test. This 
has meant we’ve not enabled parallelisation by default yet.

· RP is compiling a list of broken selftests so we can figure out 
fixing them by monitoring the repository for changes as the tests run. If 
anyone is interested in helping let us know! Faster oe-selftest times mean 
faster patch testing and merging.

· We lack a good mechanism for flagging work which someone new to the 
project who wants to help could take on. Richard posted one such task onto the 
OE-Core mailing list last week (“OE-core] Request for help - Simple 
cleanup/optimisation task”)

· Master now has significant parallelism improvements for do_package 
which take the wall clock time for ltp from 605s to 163s. Some of that was 
through parallel execution of tasks, removal of the use of subprocess shells 
also helped.


Planned Releases for YP 2.6:

· YP 2.6 M2 Build ia in QA.

· YP 2.6 M2 Release Target is July 27, 2018

· YP 2.6 M3 Build Target is Aug. 27, 2018

· YP 2.6 M3 Release Target is Sept. 7, 2018

· YP 2.6 M4 Build Target is Oct. 1, 2018

· YP 2.6 M4 Release Target is Oct. 26, 2018


Planned upcoming dot releases:

· YP 2.5.1 (Sumo) will be targeted after YP 2.6 M2 is done.

· YP 2.4.4 (Rocko) will be targeted after YP 2.6 M4 is done.


Tracking Metrics:

· WDD 2618 (last week 2646) 
(https://wiki.yoctoproject.org/charts/combo.html)

· Poky Patch Metrics

oTotal patches found: 1619 (last week 1628)

oPercentage of patches in the Pending State: 762 (46%) [last week 762 (47%)]


Key Status Links for YP:

https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.6_Status

https://wiki.yoctoproject.org/wiki/Yocto_2.6_Schedule

https://wiki.yoctoproject.org/wiki/Yocto_2.6_Features


The Status reports are now stored on the wiki at: 
https://wiki.yoctoproject.org/wiki/Weekly_Status


[If anyone has suggestions for other information you’d like to see on this 
weekly status update, let us know!]

Thanks,

Stephen K. Jolley
Yocto Project Program Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
•Cell:(208) 244-4460
• Email: stephen.k.jol...@intel.com

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


Re: [OE-core] [PATCH] defaultsetup.conf: Enable security flags+pie by default

2018-07-24 Thread Khem Raj
On Mon, Jul 23, 2018 at 11:42 PM Anuj Mittal  wrote:
>
> On 07/24/2018 03:09 AM, Khem Raj wrote:
> > This has been an opt-in for so long, some distributions e.g.
> > poky-lsb uses it by default however, since most of linux
> > distros have started to default to these settings for security
> > enhancements, time has come for OE to make it default too
>
> Should be removed from poky-lsb in that case otherwise gives duplicate
> inclusion warnings.
>

yes. after this patch lands we can do that.

> >
> > Signed-off-by: Khem Raj 
> > ---
> >  meta/conf/distro/defaultsetup.conf | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/meta/conf/distro/defaultsetup.conf 
> > b/meta/conf/distro/defaultsetup.conf
> > index ca2f9178d2..352e279596 100644
> > --- a/meta/conf/distro/defaultsetup.conf
> > +++ b/meta/conf/distro/defaultsetup.conf
> > @@ -1,6 +1,7 @@
> >  include conf/distro/include/default-providers.inc
> >  include conf/distro/include/default-versions.inc
> >  include conf/distro/include/default-distrovars.inc
> > +require conf/distro/include/security_flags.inc
> >  include conf/distro/include/world-broken.inc
> >
> >  TCMODE ?= "default"
> >
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] defaultsetup.conf: Enable security flags+pie by default

2018-07-24 Thread Khem Raj
On Tue, Jul 24, 2018 at 12:30 AM ChenQi  wrote:
>
> Hi Khem,
>
> The comments in security-flags.inc also needs to be modified to remove
> 'poky-lsb' info.
>
> I'd suggest we still put it into distro conf file (poky.conf) instead of
> defaultsetup.conf, because defaultsetup.conf is included by
> bitbake.conf. I think things in defaultsetup.conf should be necessary
> default values to build things out. I don't think security flags is
> necessary to build things out.

this is the default setup, even non-poky users will get consistent experience.

>
> Also, I got a question when I just looked at this file.
> Do you think we should adjust CFLAGS and LDFALGS in security_flags.inc
> instead of the current TARGET_CC_ARCH and TARGET_LDFLAGS?

in many cases packages do not honor CFLAGS/LDFLAGS say during configure

We are naming
> variables to SECURITY_CFLAGS and SECURITY_LDFLAGS, it seems that they
> belong to CFLAGS and LDFLAGS naturally. But I'm not sure about it.
>
yes they do, but this makes it easy to override the setting for packages where
these options are needed to be overridden or modified.


> Best Regards,
> Chen Qi
>
>
> On 07/24/2018 03:09 AM, Khem Raj wrote:
> > This has been an opt-in for so long, some distributions e.g.
> > poky-lsb uses it by default however, since most of linux
> > distros have started to default to these settings for security
> > enhancements, time has come for OE to make it default too
> >
> > Signed-off-by: Khem Raj 
> > ---
> >   meta/conf/distro/defaultsetup.conf | 1 +
> >   1 file changed, 1 insertion(+)
> >
> > diff --git a/meta/conf/distro/defaultsetup.conf 
> > b/meta/conf/distro/defaultsetup.conf
> > index ca2f9178d2..352e279596 100644
> > --- a/meta/conf/distro/defaultsetup.conf
> > +++ b/meta/conf/distro/defaultsetup.conf
> > @@ -1,6 +1,7 @@
> >   include conf/distro/include/default-providers.inc
> >   include conf/distro/include/default-versions.inc
> >   include conf/distro/include/default-distrovars.inc
> > +require conf/distro/include/security_flags.inc
> >   include conf/distro/include/world-broken.inc
> >
> >   TCMODE ?= "default"
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] Setting include path in a recipe

2018-07-24 Thread Adam Lee
How do I defined a custom include path for an autotools recipe?

This may as well be explained somewhere in the reference manual, but I
can't seem to find it.

Thank you,

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


Re: [OE-core] [PATCH v5 6/6] gstreamer1.0-libav: Replace German umlaut to avoid parsing problems

2018-07-24 Thread Burton, Ross
I'll just drop it, no need to resend.

Thanks
Ross

On 24 July 2018 at 14:15, Carlos Rafael Giani  wrote:
> I wanted to add details to this as a response to your comment, but my old
> setup where this happens now refuses to work anymore, and I don't remember
> said details.
>
> Okay, I propose we skip this patch and commit it later in case this problem
> reappears.
>
> Is a v6 necessary now, or can patchwork skip the last patch?
>
>
>
> On 2018-07-24 13:04, Burton, Ross wrote:
>>
>> It can? Where?  That's surely a bug...
>>
>> Ross
>>
>> On 24 July 2018 at 11:52, Carlos Rafael Giani 
>> wrote:
>>>
>>> The umlaut can cause issues related to encoding; avoid by replacing it
>>>
>>> Signed-off-by: Carlos Rafael Giani 
>>> ---
>>>   .../workaround-to-build-gst-libav-for-i586-with-gcc.patch   | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git
>>> a/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav/workaround-to-build-gst-libav-for-i586-with-gcc.patch
>>> b/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav/workaround-to-build-gst-libav-for-i586-with-gcc.patch
>>> index 36abf8607e..5355480aa4 100644
>>> ---
>>> a/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav/workaround-to-build-gst-libav-for-i586-with-gcc.patch
>>> +++
>>> b/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav/workaround-to-build-gst-libav-for-i586-with-gcc.patch
>>> @@ -1,5 +1,5 @@
>>>   Description: Workaround to build libav for i586 with gcc 4.9.2 by
>>> avoiding memset
>>> -Author: Bernhard Übelacker 
>>> +Author: Bernhard Uebelacker 
>>>
>>>   ---
>>>   Bug-Debian: https://bugs.debian.org/783082
>>> --
>>> 2.17.1
>>>
>>> --
>>> ___
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH v5 6/6] gstreamer1.0-libav: Replace German umlaut to avoid parsing problems

2018-07-24 Thread Carlos Rafael Giani
I wanted to add details to this as a response to your comment, but my 
old setup where this happens now refuses to work anymore, and I don't 
remember said details.


Okay, I propose we skip this patch and commit it later in case this 
problem reappears.


Is a v6 necessary now, or can patchwork skip the last patch?


On 2018-07-24 13:04, Burton, Ross wrote:

It can? Where?  That's surely a bug...

Ross

On 24 July 2018 at 11:52, Carlos Rafael Giani  wrote:

The umlaut can cause issues related to encoding; avoid by replacing it

Signed-off-by: Carlos Rafael Giani 
---
  .../workaround-to-build-gst-libav-for-i586-with-gcc.patch   | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav/workaround-to-build-gst-libav-for-i586-with-gcc.patch
 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav/workaround-to-build-gst-libav-for-i586-with-gcc.patch
index 36abf8607e..5355480aa4 100644
--- 
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav/workaround-to-build-gst-libav-for-i586-with-gcc.patch
+++ 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav/workaround-to-build-gst-libav-for-i586-with-gcc.patch
@@ -1,5 +1,5 @@
  Description: Workaround to build libav for i586 with gcc 4.9.2 by avoiding 
memset
-Author: Bernhard Übelacker 
+Author: Bernhard Uebelacker 

  ---
  Bug-Debian: https://bugs.debian.org/783082
--
2.17.1

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


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


[OE-core] [PATCH] shadow: fix CVE-2017-2616

2018-07-24 Thread Andrej Valek
Signed-off-by: Andrej Valek 
---
 .../shadow/files/CVE-2017-2616.patch   | 64 ++
 meta/recipes-extended/shadow/shadow.inc|  1 +
 2 files changed, 65 insertions(+)
 create mode 100644 meta/recipes-extended/shadow/files/CVE-2017-2616.patch

diff --git a/meta/recipes-extended/shadow/files/CVE-2017-2616.patch 
b/meta/recipes-extended/shadow/files/CVE-2017-2616.patch
new file mode 100644
index 00..ee728f0952
--- /dev/null
+++ b/meta/recipes-extended/shadow/files/CVE-2017-2616.patch
@@ -0,0 +1,64 @@
+shadow-4.2.1: Fix CVE-2017-2616
+
+[No upstream tracking] -- 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855943
+
+su: properly clear child PID
+
+If su is compiled with PAM support, it is possible for any local user
+to send SIGKILL to other processes with root privileges. There are
+only two conditions. First, the user must be able to perform su with
+a successful login. This does NOT have to be the root user, even using
+su with the same id is enough, e.g. "su $(whoami)". Second, SIGKILL
+can only be sent to processes which were executed after the su process.
+It is not possible to send SIGKILL to processes which were already
+running. I consider this as a security vulnerability, because I was
+able to write a proof of concept which unlocked a screen saver of
+another user this way.
+
+Upstream-Status: Backport 
[https://github.com/shadow-maint/shadow/commit/08fd4b69e84364677a10e519ccb25b71710ee686]
+CVE: CVE-2017-2616
+bug: 855943
+Signed-off-by: Andrej Valek 
+
+diff --git a/src/su.c b/src/su.c
+index 3704217..1efcd61 100644
+--- a/src/su.c
 b/src/su.c
+@@ -363,20 +363,35 @@ static void prepare_pam_close_session (void)
+   /* wake child when resumed */
+   kill (pid, SIGCONT);
+   stop = false;
++  } else {
++  pid_child = 0;
+   }
+   } while (!stop);
+   }
+ 
+-  if (0 != caught) {
++  if (0 != caught && 0 != pid_child) {
+   (void) fputs ("\n", stderr);
+   (void) fputs (_("Session terminated, terminating shell..."),
+ stderr);
+   (void) kill (-pid_child, caught);
+ 
+   (void) signal (SIGALRM, kill_child);
++  (void) signal (SIGCHLD, catch_signals);
+   (void) alarm (2);
+ 
+-  (void) wait ();
++  sigemptyset ();
++  if ((sigaddset (, SIGALRM) != 0)
++  || (sigprocmask (SIG_BLOCK, , NULL) != 0)) {
++  fprintf (stderr, _("%s: signal masking malfunction\n"), 
Prog);
++  kill_child (0);
++  } else {
++  while (0 == waitpid (pid_child, , WNOHANG)) {
++  sigsuspend ();
++  }
++  pid_child = 0;
++  (void) sigprocmask (SIG_UNBLOCK, , NULL);
++  }
++
+   (void) fputs (_(" ...terminated.\n"), stderr);
+   }
+ 
diff --git a/meta/recipes-extended/shadow/shadow.inc 
b/meta/recipes-extended/shadow/shadow.inc
index 9a08918818..6efe4a9119 100644
--- a/meta/recipes-extended/shadow/shadow.inc
+++ b/meta/recipes-extended/shadow/shadow.inc
@@ -18,6 +18,7 @@ SRC_URI = 
"https://downloads.yoctoproject.org/mirror/sources/${BP}.tar.xz \
file://check_size_of_uid_t_and_gid_t_using_AC_CHECK_SIZEOF.patch \
file://0001-useradd-copy-extended-attributes-of-home.patch \
file://0001-shadow-CVE-2017-12424 \
+   file://CVE-2017-2616.patch \
${@bb.utils.contains('PACKAGECONFIG', 'pam', '${PAM_SRC_URI}', '', 
d)} \
"
 
-- 
2.11.0

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


[OE-core] ✗ patchtest: failure for "[v5] gstreamer1.0-plugin-base:..." and 5 more

2018-07-24 Thread Patchwork
== Series Details ==

Series: "[v5] gstreamer1.0-plugin-base:..." and 5 more
Revision: 1
URL   : https://patchwork.openembedded.org/series/13175/
State : failure

== Summary ==


Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
series by patchtest resulting in the following failures:



* Issue Series does not apply on top of target branch 
[test_series_merge_on_head] 
  Suggested fixRebase your series on top of targeted branch
  Targeted branch  master (currently at f9c233908e)



If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).

---
Guidelines: 
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

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


Re: [OE-core] [PATCH v5 6/6] gstreamer1.0-libav: Replace German umlaut to avoid parsing problems

2018-07-24 Thread Burton, Ross
It can? Where?  That's surely a bug...

Ross

On 24 July 2018 at 11:52, Carlos Rafael Giani  wrote:
> The umlaut can cause issues related to encoding; avoid by replacing it
>
> Signed-off-by: Carlos Rafael Giani 
> ---
>  .../workaround-to-build-gst-libav-for-i586-with-gcc.patch   | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git 
> a/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav/workaround-to-build-gst-libav-for-i586-with-gcc.patch
>  
> b/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav/workaround-to-build-gst-libav-for-i586-with-gcc.patch
> index 36abf8607e..5355480aa4 100644
> --- 
> a/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav/workaround-to-build-gst-libav-for-i586-with-gcc.patch
> +++ 
> b/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav/workaround-to-build-gst-libav-for-i586-with-gcc.patch
> @@ -1,5 +1,5 @@
>  Description: Workaround to build libav for i586 with gcc 4.9.2 by avoiding 
> memset
> -Author: Bernhard Übelacker 
> +Author: Bernhard Uebelacker 
>
>  ---
>  Bug-Debian: https://bugs.debian.org/783082
> --
> 2.17.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH 3/6] package: Use subprocess to be consistent with the rest of the class

2018-07-24 Thread Richard Purdie
Using 'sub' in one function just confuses things, standardise and fix
formatting of the parameters too.

Signed-off-by: Richard Purdie 
---
 meta/classes/package.bbclass | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index df5206bda9e..be76b30f31c 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -1575,7 +1575,7 @@ SHLIBSWORKDIR = "${PKGDESTWORK}/${MLPREFIX}shlibs2"
 
 python package_do_shlibs() {
 import re, pipes
-import subprocess as sub
+import subprocess
 
 exclude_shlibs = d.getVar('EXCLUDE_FROM_SHLIBS', False)
 if exclude_shlibs:
@@ -1677,7 +1677,7 @@ python package_do_shlibs() {
 sonames.add(prov)
 if file.endswith('.dylib') or file.endswith('.so'):
 rpath = []
-p = sub.Popen([d.expand("${HOST_PREFIX}otool"), '-l', 
file],stdout=sub.PIPE,stderr=sub.PIPE)
+p = subprocess.Popen([d.expand("${HOST_PREFIX}otool"), '-l', 
file], stdout=subprocess.PIPE, stderr=subprocess.PIPE)
 out, err = p.communicate()
 # If returned successfully, process stdout for results
 if p.returncode == 0:
@@ -1686,7 +1686,7 @@ python package_do_shlibs() {
 if l.startswith('path '):
 rpath.append(l.split()[1])
 
-p = sub.Popen([d.expand("${HOST_PREFIX}otool"), '-L', 
file],stdout=sub.PIPE,stderr=sub.PIPE)
+p = subprocess.Popen([d.expand("${HOST_PREFIX}otool"), '-L', file], 
stdout=subprocess.PIPE, stderr=subprocess.PIPE)
 out, err = p.communicate()
 # If returned successfully, process stdout for results
 if p.returncode == 0:
@@ -1710,7 +1710,7 @@ python package_do_shlibs() {
 
 if (file.endswith(".dll") or file.endswith(".exe")):
 # use objdump to search for "DLL Name: .*\.dll"
-p = sub.Popen([d.expand("${HOST_PREFIX}objdump"), "-p", file], 
stdout = sub.PIPE, stderr= sub.PIPE)
+p = subprocess.Popen([d.expand("${HOST_PREFIX}objdump"), "-p", 
file], stdout=subprocess.PIPE, stderr=subprocess.PIPE)
 out, err = p.communicate()
 # process the output, grabbing all .dll names
 if p.returncode == 0:
-- 
2.17.1

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


[OE-core] [PATCH 5/6] license_image: Fix race

2018-07-24 Thread Richard Purdie
The current code pokes into do_deploy manifests from do_image_complete when the
do_image_complete task may or may not depend upon the do_deploy tasks in 
question.
Often it gets lucky, sometimes it results in build failures.

To fix this, split the functionality to its own task which can have the correct
task dependencies. This means the data in BB_TASKDEPDATA is definitive, the 
other
code can be dropped, as can the IMAGE_EXTRATYPES do_populate_lic dependencies
from image.bbclass.

This fixes bugs which show up as:

NOTE: recipe linux-yocto-4.14.48+gitAUTOINC+d64aec9793_97c8063d2d-r0: task 
do_deploy: Started
ERROR: core-image-minimal-1.0-r0 do_image_complete: Error executing a python 
function in exec_python_func() autogenerated:

The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: 
 0001:
 *** 0002:write_deploy_manifest(d)
 0003:
File: 
'/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oe-selftest/build/meta/classes/license.bbclass',
 lineno: 33, function: write_deploy_manifest
 0029:'w+').write(output)
 0030:}
 0031:
 0032:python write_deploy_manifest() {
 *** 0033:license_deployed_manifest(d)
 0034:}
 0035:
 0036:python license_create_manifest() {
 0037:import oe.packagedata
File: 
'/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oe-selftest/build/meta/classes/license.bbclass',
 lineno: 191, function: license_deployed_manifest
 0187:# It is necessary to mark this will be used for image manifest
 0188:man_dic[dep]["IMAGE_MANIFEST"] = True
 0189:man_dic[dep]["PN"] = dep
 0190:man_dic[dep]["FILES"] = \
 *** 0191:" ".join(get_deployed_files(dep_dic[dep]))
 0192:with open(os.path.join(lic_dir, dep, "recipeinfo"), "r") as f:
 0193:for line in f.readlines():
 0194:key,val = line.split(": ", 1)
 0195:man_dic[dep][key] = val[:-1]
File: 
'/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oe-selftest/build/meta/classes/license.bbclass',
 lineno: 289, function: get_deployed_files
 0285:"""
 0286:
 0287:dep_files = []
 0288:excluded_files = []
 *** 0289:with open(man_file, "r") as manifest:
 0290:all_files = manifest.read()
 0291:for f in all_files.splitlines():
 0292:if ((not (os.path.islink(f) or os.path.isdir(f))) and
 0293:not os.path.basename(f) in excluded_files):
Exception: FileNotFoundError: [Errno 2] No such file or directory: 
'/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oe-selftest/build/build-st-730/tmp/sstate-control/manifest-qemux86_64-linux-yocto.deploy'

ERROR: core-image-minimal-1.0-r0 do_image_complete: Function failed: 
write_deploy_manifest
ERROR: Logfile of failure stored in: 
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oe-selftest/build/build-st-730/tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/temp/log.do_image_complete.50537
NOTE: recipe core-image-minimal-1.0-r0: task do_image_complete: Failed
ERROR: Task 
(/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oe-selftest/build/meta/recipes-core/images/core-image-minimal.bb:do_image_complete)
 failed with exit code '1'
NOTE: recipe linux-yocto-4.14.48+gitAUTOINC+d64aec9793_97c8063d2d-r0: task 
do_deploy: Succeeded

Signed-off-by: Richard Purdie 
---
 meta/classes/image.bbclass |  1 -
 meta/classes/license_image.bbclass | 58 --
 2 files changed, 6 insertions(+), 53 deletions(-)

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index adc50c99bcd..c3e73676dca 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -141,7 +141,6 @@ python () {
 deps += " %s:%s" % (dep, task)
 return deps
 
-d.appendVarFlag('do_image', 'depends', 
extraimage_getdepends('do_populate_lic'))
 d.appendVarFlag('do_image_complete', 'depends', 
extraimage_getdepends('do_populate_sysroot'))
 
 deps = " " + imagetypes_getdepends(d)
diff --git a/meta/classes/license_image.bbclass 
b/meta/classes/license_image.bbclass
index efeedce519f..f0fbb763f1d 100644
--- a/meta/classes/license_image.bbclass
+++ b/meta/classes/license_image.bbclass
@@ -11,10 +11,6 @@ python write_package_manifest() {
 'w+').write(output)
 }
 
-python write_deploy_manifest() {
-license_deployed_manifest(d)
-}
-
 python license_create_manifest() {
 import oe.packagedata
 from oe.rootfs import image_list_installed_packages
@@ -197,11 +193,6 @@ def get_deployed_dependencies(d):
 depends = list(set([dep[0] for dep
 in list(taskdata.values())
 if not dep[0].endswith("-native")]))
-extra_depends = d.getVar("EXTRA_IMAGEDEPENDS")
-boot_depends = get_boot_dependencies(d)
-depends.extend(extra_depends.split())
-

[OE-core] [PATCH 4/6] license: Split image license functions to a separate class

2018-07-24 Thread Richard Purdie
This means the image code is only included in image recipes through
the IMAGE_CLASSES variable.

This sets things up to allow us to fix image deploy dependency problems.

Signed-off-by: Richard Purdie 
---
 meta/classes/license.bbclass   | 284 +
 meta/classes/license_image.bbclass | 284 +
 2 files changed, 285 insertions(+), 283 deletions(-)
 create mode 100644 meta/classes/license_image.bbclass

diff --git a/meta/classes/license.bbclass b/meta/classes/license.bbclass
index 141af5de4d3..2ac15a1bc89 100644
--- a/meta/classes/license.bbclass
+++ b/meta/classes/license.bbclass
@@ -16,284 +16,6 @@ addtask populate_lic after do_patch before do_build
 do_populate_lic[dirs] = "${LICSSTATEDIR}/${PN}"
 do_populate_lic[cleandirs] = "${LICSSTATEDIR}"
 
-python write_package_manifest() {
-# Get list of installed packages
-license_image_dir = d.expand('${LICENSE_DIRECTORY}/${IMAGE_NAME}')
-bb.utils.mkdirhier(license_image_dir)
-from oe.rootfs import image_list_installed_packages
-from oe.utils import format_pkg_list
-
-pkgs = image_list_installed_packages(d)
-output = format_pkg_list(pkgs)
-open(os.path.join(license_image_dir, 'package.manifest'),
-'w+').write(output)
-}
-
-python write_deploy_manifest() {
-license_deployed_manifest(d)
-}
-
-python license_create_manifest() {
-import oe.packagedata
-from oe.rootfs import image_list_installed_packages
-
-build_images_from_feeds = d.getVar('BUILD_IMAGES_FROM_FEEDS')
-if build_images_from_feeds == "1":
-return 0
-
-pkg_dic = {}
-for pkg in sorted(image_list_installed_packages(d)):
-pkg_info = os.path.join(d.getVar('PKGDATA_DIR'),
-'runtime-reverse', pkg)
-pkg_name = os.path.basename(os.readlink(pkg_info))
-
-pkg_dic[pkg_name] = oe.packagedata.read_pkgdatafile(pkg_info)
-if not "LICENSE" in pkg_dic[pkg_name].keys():
-pkg_lic_name = "LICENSE_" + pkg_name
-pkg_dic[pkg_name]["LICENSE"] = pkg_dic[pkg_name][pkg_lic_name]
-
-rootfs_license_manifest = os.path.join(d.getVar('LICENSE_DIRECTORY'),
-d.getVar('IMAGE_NAME'), 'license.manifest')
-write_license_files(d, rootfs_license_manifest, pkg_dic)
-}
-
-def write_license_files(d, license_manifest, pkg_dic):
-import re
-
-bad_licenses = (d.getVar("INCOMPATIBLE_LICENSE") or "").split()
-bad_licenses = map(lambda l: canonical_license(d, l), bad_licenses)
-bad_licenses = expand_wildcard_licenses(d, bad_licenses)
-
-with open(license_manifest, "w") as license_file:
-for pkg in sorted(pkg_dic):
-if bad_licenses:
-try:
-(pkg_dic[pkg]["LICENSE"], pkg_dic[pkg]["LICENSES"]) = \
-oe.license.manifest_licenses(pkg_dic[pkg]["LICENSE"],
-bad_licenses, canonical_license, d)
-except oe.license.LicenseError as exc:
-bb.fatal('%s: %s' % (d.getVar('P'), exc))
-else:
-pkg_dic[pkg]["LICENSES"] = re.sub('[|&()*]', ' ', 
pkg_dic[pkg]["LICENSE"])
-pkg_dic[pkg]["LICENSES"] = re.sub('  *', ' ', 
pkg_dic[pkg]["LICENSES"])
-pkg_dic[pkg]["LICENSES"] = pkg_dic[pkg]["LICENSES"].split()
-
-if not "IMAGE_MANIFEST" in pkg_dic[pkg]:
-# Rootfs manifest
-license_file.write("PACKAGE NAME: %s\n" % pkg)
-license_file.write("PACKAGE VERSION: %s\n" % 
pkg_dic[pkg]["PV"])
-license_file.write("RECIPE NAME: %s\n" % pkg_dic[pkg]["PN"])
-license_file.write("LICENSE: %s\n\n" % pkg_dic[pkg]["LICENSE"])
-
-# If the package doesn't contain any file, that is, its size 
is 0, the license
-# isn't relevant as far as the final image is concerned. So 
doing license check
-# doesn't make much sense, skip it.
-if pkg_dic[pkg]["PKGSIZE_%s" % pkg] == "0":
-continue
-else:
-# Image manifest
-license_file.write("RECIPE NAME: %s\n" % pkg_dic[pkg]["PN"])
-license_file.write("VERSION: %s\n" % pkg_dic[pkg]["PV"])
-license_file.write("LICENSE: %s\n" % pkg_dic[pkg]["LICENSE"])
-license_file.write("FILES: %s\n\n" % pkg_dic[pkg]["FILES"])
-
-for lic in pkg_dic[pkg]["LICENSES"]:
-lic_file = os.path.join(d.getVar('LICENSE_DIRECTORY'),
-pkg_dic[pkg]["PN"], "generic_%s" % 
-re.sub('\+', '', lic))
-# add explicity avoid of CLOSED license because isn't generic
-if lic == "CLOSED":
-   continue
-
-if not os.path.exists(lic_file):
-   bb.warn("The license listed %s was not in the "\ 
-  

[OE-core] [PATCH 6/6] uninative-tarball: Add nativesdk-libnss-nis to resolve glibc symbol issues

2018-07-24 Thread Richard Purdie
We need this to avoid symbol mismatch issues for binaries that use this
on newer systems which then won't run on older ones where it isn't present.

Signed-off-by: Richard Purdie 
---
 meta/recipes-core/meta/uninative-tarball.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-core/meta/uninative-tarball.bb 
b/meta/recipes-core/meta/uninative-tarball.bb
index c38c2a445e9..e0cb9ffee0d 100644
--- a/meta/recipes-core/meta/uninative-tarball.bb
+++ b/meta/recipes-core/meta/uninative-tarball.bb
@@ -16,6 +16,7 @@ TOOLCHAIN_HOST_TASK = "\
 nativesdk-glibc-gconv-libjis \
 nativesdk-patchelf \
 nativesdk-libxcrypt \
+nativesdk-libnss-nis \
 "
 
 INHIBIT_DEFAULT_DEPS = "1"
-- 
2.17.1

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


[OE-core] [PATCH v5 1/6] gstreamer1.0-plugin-base: Update packageconfigs

2018-07-24 Thread Carlos Rafael Giani
* Add patches for gbm, libpng, libjpeg to conditionally enable/disable
  them in the configure script
* Reorder the packageconfigs alphabetically

Signed-off-by: Carlos Rafael Giani 
---
 ...r-explicitely-enabling-disabling-GBM.patch |  70 +++
 ...for-explicitely-enabling-disabling-P.patch | 109 ++
 .../gstreamer1.0-plugins-base_1.14.1.bb   |  24 ++--
 3 files changed, 194 insertions(+), 9 deletions(-)
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0010-gl-Add-switch-for-explicitely-enabling-disabling-GBM.patch
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0011-gl-Add-switches-for-explicitely-enabling-disabling-P.patch

diff --git 
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0010-gl-Add-switch-for-explicitely-enabling-disabling-GBM.patch
 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0010-gl-Add-switch-for-explicitely-enabling-disabling-GBM.patch
new file mode 100644
index 00..45ba50750d
--- /dev/null
+++ 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0010-gl-Add-switch-for-explicitely-enabling-disabling-GBM.patch
@@ -0,0 +1,70 @@
+From a1b59ca6b1781442f37ffc1b697635db126b3a22 Mon Sep 17 00:00:00 2001
+From: Carlos Rafael Giani 
+Date: Thu, 19 Jul 2018 10:30:54 +0200
+Subject: [PATCH] gl: Add switch for explicitely enabling/disabling GBM support
+
+Upstream-Status: Submitted [https://bugzilla.gnome.org/show_bug.cgi?id=796833]
+
+Signed-off-by: Carlos Rafael Giani 
+---
+ m4/gst-gl.m4 | 30 --
+ 1 file changed, 28 insertions(+), 2 deletions(-)
+
+diff --git a/m4/gst-gl.m4 b/m4/gst-gl.m4
+index 1e9724094..aca5295cc 100644
+--- a/m4/gst-gl.m4
 b/m4/gst-gl.m4
+@@ -117,6 +117,15 @@ AC_ARG_ENABLE([dispmanx],
+*) AC_MSG_ERROR([bad value ${enableval} for --enable-dispmanx]) ;;
+  esac],[NEED_DISPMANX=auto])
+ 
++AC_ARG_ENABLE([gbm],
++ [  --enable-gbmEnable Mesa3D GBM support (requires EGL) 
@<:@default=auto@:>@],
++ [case "${enableval}" in
++   yes)  NEED_GBM=yes ;;
++   no)   NEED_GBM=no ;;
++   auto) NEED_GBM=auto ;;
++   *) AC_MSG_ERROR([bad value ${enableval} for --enable-gbm]) ;;
++ esac],[NEED_GBM=auto])
++
+ AG_GST_PKG_CHECK_MODULES(X11_XCB, x11-xcb)
+ save_CPPFLAGS="$CPPFLAGS"
+ save_LIBS="$LIBS"
+@@ -172,15 +181,32 @@ case $host in
+ AC_CHECK_LIB([EGL], [fbGetDisplay], [HAVE_VIV_FB_EGL=yes])
+ fi
+ 
+-if test "x$HAVE_EGL" = "xyes"; then
++if test "x$NEED_GBM" != "xno"; then
++  if test "x$HAVE_EGL" = "xyes"; then
+ PKG_CHECK_MODULES(DRM, libdrm >= 2.4.55, HAVE_DRM=yes, HAVE_DRM=no)
+ AC_SUBST(DRM_CFLAGS)
+ AC_SUBST(DRM_LIBS)
++if test "x$NEED_GBM" = "xyes"; then
++  if test "x$HAVE_DRM" = "xno"; then
++AC_MSG_ERROR([GBM support requested but libdrm is not available])
++  fi
++  if test "x$HAVE_GUDEV" = "xno"; then
++AC_MSG_ERROR([GBM support requested but gudev is not available])
++  fi
++fi
+ if test "x$HAVE_DRM" = "xyes" -a "x$HAVE_GUDEV" = "xyes"; then
+   PKG_CHECK_MODULES(GBM, gbm, HAVE_GBM_EGL=yes, HAVE_GBM_EGL=no)
++  if test "x$HAVE_GBM_EGL" = "xno" -a "x$NEED_GBM" = "xyes"; then
++AC_MSG_ERROR([GBM support requested but gbm library is not 
available])
++  fi
+   AC_SUBST(GBM_CFLAGS)
+   AC_SUBST(GBM_LIBS)
+-   fi
++fi
++  elif test "x$NEED_GBM" = "xyes"; then
++AC_MSG_ERROR([GBM support requested but EGL is not available])
++  else
++AC_MSG_NOTICE([GBM support requested but EGL is not available; not 
enabling GBM support])
++  fi
+ fi
+ 
+ dnl FIXME: Mali EGL depends on GLESv1 or GLESv2
+-- 
+2.17.1
+
diff --git 
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0011-gl-Add-switches-for-explicitely-enabling-disabling-P.patch
 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0011-gl-Add-switches-for-explicitely-enabling-disabling-P.patch
new file mode 100644
index 00..65d191a396
--- /dev/null
+++ 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0011-gl-Add-switches-for-explicitely-enabling-disabling-P.patch
@@ -0,0 +1,109 @@
+From 092aadfc1df69c46d920b0cd39f98d363d6988b3 Mon Sep 17 00:00:00 2001
+From: Carlos Rafael Giani 
+Date: Thu, 19 Jul 2018 11:16:05 +0200
+Subject: [PATCH] gl: Add switches for explicitely enabling/disabling PNG and
+ JPEG support
+
+Upstream-Status: Submitted [https://bugzilla.gnome.org/show_bug.cgi?id=796833]
+
+Signed-off-by: Carlos Rafael Giani 
+---
+ m4/gst-gl.m4 | 66 
+ 1 file changed, 46 insertions(+), 20 deletions(-)
+
+diff --git a/m4/gst-gl.m4 b/m4/gst-gl.m4
+index 20b2233de..f8809981c 100644
+--- a/m4/gst-gl.m4
 b/m4/gst-gl.m4
+@@ -126,6 +126,24 @@ AC_ARG_ENABLE([gbm],
+*) AC_MSG_ERROR([bad value 

[OE-core] [PATCH v5 5/6] gstreamer1.0-vaapi: Add patch for EGL CFLAGS for proper EGL support

2018-07-24 Thread Carlos Rafael Giani
Signed-off-by: Carlos Rafael Giani 
---
 ...le.am-Add-EGL_CFLAGS-to-libgstvaapi-.patch | 33 +++
 .../gstreamer/gstreamer1.0-vaapi_1.14.1.bb|  1 +
 2 files changed, 34 insertions(+)
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi/0001-gst-vaapi-Makefile.am-Add-EGL_CFLAGS-to-libgstvaapi-.patch

diff --git 
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi/0001-gst-vaapi-Makefile.am-Add-EGL_CFLAGS-to-libgstvaapi-.patch
 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi/0001-gst-vaapi-Makefile.am-Add-EGL_CFLAGS-to-libgstvaapi-.patch
new file mode 100644
index 00..d7b8984953
--- /dev/null
+++ 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi/0001-gst-vaapi-Makefile.am-Add-EGL_CFLAGS-to-libgstvaapi-.patch
@@ -0,0 +1,33 @@
+From 5403a89e6a7ac72a23e0221075c0c19b5f85a021 Mon Sep 17 00:00:00 2001
+From: Fabio Berton 
+Date: Wed, 13 Jun 2018 09:09:25 -0300
+Subject: [PATCH] gst/vaapi/Makefile.am: Add EGL_CFLAGS to libgstvaapi CFLAGS
+Organization: O.S. Systems Software LTDA.
+
+We need this to pass correctly EGL CFLAGS when building with EGL support.
+
+Upstream-Status: Pending
+
+Signed-off-by: Fabio Berton 
+---
+ gst/vaapi/Makefile.am | 4 
+ 1 file changed, 4 insertions(+)
+
+diff --git a/gst/vaapi/Makefile.am b/gst/vaapi/Makefile.am
+index b299ac98..d6cab71f 100644
+--- a/gst/vaapi/Makefile.am
 b/gst/vaapi/Makefile.am
+@@ -24,6 +24,10 @@ libgstvaapi_LIBS += 
$(top_builddir)/gst-libs/gst/vaapi/libgstvaapi-glx.la
+ endif
+ 
+ if USE_EGL
++libgstvaapi_CFLAGS += \
++  $(EGL_CFLAGS)   \
++  $(NULL)
++
+ libgstvaapi_LIBS += $(top_builddir)/gst-libs/gst/vaapi/libgstvaapi-egl.la
+ endif
+ 
+-- 
+2.17.1
+
diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.14.1.bb 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.14.1.bb
index e647458fab..63290326a5 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.14.1.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.14.1.bb
@@ -9,6 +9,7 @@ LICENSE = "LGPLv2.1+"
 LIC_FILES_CHKSUM = "file://COPYING.LIB;md5=4fbd65380cdd255951079008b364516c"
 
 SRC_URI = 
"https://gstreamer.freedesktop.org/src/${REALPN}/${REALPN}-${PV}.tar.xz \
+   
file://0001-gst-vaapi-Makefile.am-Add-EGL_CFLAGS-to-libgstvaapi-.patch \
   "
 
 SRC_URI[md5sum] = "38c5b2390797b7a0a269a5ab6c8cbe8f"
-- 
2.17.1

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


[OE-core] [PATCH v5 4/6] gstreamer1.0-vaapi: Remove unnecessary FILESPATH modification

2018-07-24 Thread Carlos Rafael Giani
Signed-off-by: Carlos Rafael Giani 
---
 meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.14.1.bb | 1 -
 1 file changed, 1 deletion(-)

diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.14.1.bb 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.14.1.bb
index 906dc6e6c4..e647458fab 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.14.1.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.14.1.bb
@@ -4,7 +4,6 @@ based plugins for GStreamer and helper libraries: 
`vaapidecode', \
 `vaapiconvert', and `vaapisink'."
 
 REALPN = "gstreamer-vaapi"
-FILESPATH = "${@base_set_filespath(["${FILE_DIRNAME}/${REALPN}", 
"${FILE_DIRNAME}/${REALPN}"], d)}"
 
 LICENSE = "LGPLv2.1+"
 LIC_FILES_CHKSUM = "file://COPYING.LIB;md5=4fbd65380cdd255951079008b364516c"
-- 
2.17.1

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


[OE-core] [PATCH 2/6] selftest/wic: clean up runCmd error code handling

2018-07-24 Thread Richard Purdie
runCmd handles checking exit 0 internally unless specified otherwise and its
error messages are much more useful including the failed command output.

Clean up the unneeded 0 exit code checks in the wic tests.

Signed-off-by: Richard Purdie 
---
 meta/lib/oeqa/selftest/cases/wic.py | 192 
 1 file changed, 82 insertions(+), 110 deletions(-)

diff --git a/meta/lib/oeqa/selftest/cases/wic.py 
b/meta/lib/oeqa/selftest/cases/wic.py
index 6793efb62e9..cfee9d1e71d 100644
--- a/meta/lib/oeqa/selftest/cases/wic.py
+++ b/meta/lib/oeqa/selftest/cases/wic.py
@@ -99,58 +99,58 @@ class Wic(WicTestCase):
 @OETestID(1552)
 def test_version(self):
 """Test wic --version"""
-self.assertEqual(0, runCmd('wic --version').status)
+runCmd('wic --version')
 
 @OETestID(1208)
 def test_help(self):
 """Test wic --help and wic -h"""
-self.assertEqual(0, runCmd('wic --help').status)
-self.assertEqual(0, runCmd('wic -h').status)
+runCmd('wic --help')
+runCmd('wic -h')
 
 @OETestID(1209)
 def test_createhelp(self):
 """Test wic create --help"""
-self.assertEqual(0, runCmd('wic create --help').status)
+runCmd('wic create --help')
 
 @OETestID(1210)
 def test_listhelp(self):
 """Test wic list --help"""
-self.assertEqual(0, runCmd('wic list --help').status)
+runCmd('wic list --help')
 
 @OETestID(1553)
 def test_help_create(self):
 """Test wic help create"""
-self.assertEqual(0, runCmd('wic help create').status)
+runCmd('wic help create')
 
 @OETestID(1554)
 def test_help_list(self):
 """Test wic help list"""
-self.assertEqual(0, runCmd('wic help list').status)
+runCmd('wic help list')
 
 @OETestID(1215)
 def test_help_overview(self):
 """Test wic help overview"""
-self.assertEqual(0, runCmd('wic help overview').status)
+runCmd('wic help overview')
 
 @OETestID(1216)
 def test_help_plugins(self):
 """Test wic help plugins"""
-self.assertEqual(0, runCmd('wic help plugins').status)
+runCmd('wic help plugins')
 
 @OETestID(1217)
 def test_help_kickstart(self):
 """Test wic help kickstart"""
-self.assertEqual(0, runCmd('wic help kickstart').status)
+runCmd('wic help kickstart')
 
 @OETestID(1555)
 def test_list_images(self):
 """Test wic list images"""
-self.assertEqual(0, runCmd('wic list images').status)
+runCmd('wic list images')
 
 @OETestID(1556)
 def test_list_source_plugins(self):
 """Test wic list source-plugins"""
-self.assertEqual(0, runCmd('wic list source-plugins').status)
+runCmd('wic list source-plugins')
 
 @OETestID(1557)
 def test_listed_images_help(self):
@@ -158,7 +158,7 @@ class Wic(WicTestCase):
 output = runCmd('wic list images').output
 imagelist = [line.split()[0] for line in output.splitlines()]
 for image in imagelist:
-self.assertEqual(0, runCmd('wic list %s help' % image).status)
+runCmd('wic list %s help' % image)
 
 @OETestID(1213)
 def test_unsupported_subcommand(self):
@@ -174,7 +174,7 @@ class Wic(WicTestCase):
 def test_build_image_name(self):
 """Test wic create wictestdisk --image-name=core-image-minimal"""
 cmd = "wic create wictestdisk --image-name=core-image-minimal -o %s" % 
self.resultdir
-self.assertEqual(0, runCmd(cmd).status)
+runCmd(cmd)
 self.assertEqual(1, len(glob(self.resultdir + "wictestdisk-*.direct")))
 
 @OETestID(1157)
@@ -182,7 +182,7 @@ class Wic(WicTestCase):
 def test_gpt_image(self):
 """Test creation of core-image-minimal with gpt table and UUID boot"""
 cmd = "wic create directdisk-gpt --image-name core-image-minimal -o 
%s" % self.resultdir
-self.assertEqual(0, runCmd(cmd).status)
+runCmd(cmd)
 self.assertEqual(1, len(glob(self.resultdir + "directdisk-*.direct")))
 
 @OETestID(1346)
@@ -196,7 +196,7 @@ class Wic(WicTestCase):
 bitbake('core-image-minimal core-image-minimal-initramfs')
 self.remove_config(config)
 cmd = "wic create mkhybridiso --image-name core-image-minimal -o %s" % 
self.resultdir
-self.assertEqual(0, runCmd(cmd).status)
+runCmd(cmd)
 self.assertEqual(1, len(glob(self.resultdir + 
"HYBRID_ISO_IMG-*.direct")))
 self.assertEqual(1, len(glob(self.resultdir + "HYBRID_ISO_IMG-*.iso")))
 
@@ -205,7 +205,7 @@ class Wic(WicTestCase):
 def test_qemux86_directdisk(self):
 """Test creation of qemux-86-directdisk image"""
 cmd = "wic create qemux86-directdisk -e core-image-minimal -o %s" % 
self.resultdir
-self.assertEqual(0, runCmd(cmd).status)
+runCmd(cmd)
 self.assertEqual(1, len(glob(self.resultdir + 

[OE-core] [PATCH 1/6] selftest/wic: Improve error message got test_fixed_size

2018-07-24 Thread Richard Purdie
Currently this can fail with a message like 127 != 0 which is unhelpful.

If we remove the ignore_status=False, the debugging from runCmd is much
more helpful printing status.output.

Also remove the now unneeded exit code check.

Signed-off-by: Richard Purdie 
---
 meta/lib/oeqa/selftest/cases/wic.py | 2 --
 1 file changed, 2 deletions(-)

diff --git a/meta/lib/oeqa/selftest/cases/wic.py 
b/meta/lib/oeqa/selftest/cases/wic.py
index ba4d3be7a86..6793efb62e9 100644
--- a/meta/lib/oeqa/selftest/cases/wic.py
+++ b/meta/lib/oeqa/selftest/cases/wic.py
@@ -695,9 +695,7 @@ class Wic2(WicTestCase):
 
 # verify partition size with wic
 res = runCmd("parted -m %s unit mib p 2>/dev/null" % wicimg,
- ignore_status=True,
  native_sysroot=self.native_sysroot)
-self.assertEqual(0, res.status)
 
 # parse parted output which looks like this:
 # BYT;\n
-- 
2.17.1

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


[OE-core] [PATCH v5 6/6] gstreamer1.0-libav: Replace German umlaut to avoid parsing problems

2018-07-24 Thread Carlos Rafael Giani
The umlaut can cause issues related to encoding; avoid by replacing it

Signed-off-by: Carlos Rafael Giani 
---
 .../workaround-to-build-gst-libav-for-i586-with-gcc.patch   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav/workaround-to-build-gst-libav-for-i586-with-gcc.patch
 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav/workaround-to-build-gst-libav-for-i586-with-gcc.patch
index 36abf8607e..5355480aa4 100644
--- 
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav/workaround-to-build-gst-libav-for-i586-with-gcc.patch
+++ 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav/workaround-to-build-gst-libav-for-i586-with-gcc.patch
@@ -1,5 +1,5 @@
 Description: Workaround to build libav for i586 with gcc 4.9.2 by avoiding 
memset
-Author: Bernhard Übelacker 
+Author: Bernhard Uebelacker 
 
 ---
 Bug-Debian: https://bugs.debian.org/783082
-- 
2.17.1

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


[OE-core] [PATCH v5 3/6] gstreamer1.0-plugin-bad: Update packageconfigs

2018-07-24 Thread Carlos Rafael Giani
* Add packageconfigs for gl, libde265, lcms2, openh264, tinyalsa, ttml,
  webrtc, webrtcdsp
* Remove unnecessary gstglconfig.h line, since that file is no longer
  part of -bad (it is in -base now)
* Update EXTRA_OECONF flags, since new plugins got added to -bad
* Add ttml to the default packageconfigs since its dependencies are
  all in oe-core

Signed-off-by: Carlos Rafael Giani 
---
 .../gstreamer1.0-plugins-bad_1.14.1.bb| 30 +--
 1 file changed, 21 insertions(+), 9 deletions(-)

diff --git 
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.14.1.bb 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.14.1.bb
index 0e477e5a9c..64d565135b 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.14.1.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.14.1.bb
@@ -27,9 +27,14 @@ PACKAGECONFIG ??= " \
 ${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', 'bluez', '', d)} \
 ${@bb.utils.filter('DISTRO_FEATURES', 'directfb vulkan', d)} \
 ${@bb.utils.contains('DISTRO_FEATURES', 'wayland', 'wayland', '', d)} \
-bz2 curl dash dtls hls rsvg sbc smoothstreaming sndfile uvch264 webp \
+${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'gl', '', d)} \
+bz2 curl dash dtls hls rsvg sbc smoothstreaming sndfile ttml uvch264 webp \
 "
 
+# the gl packageconfig enables OpenGL elements that haven't been ported
+# to -base yet. They depend on the gstgl library in -base, so we do
+# not add GL dependencies here, since these are taken care of in -base.
+
 PACKAGECONFIG[assrender]   = 
"--enable-assrender,--disable-assrender,libass"
 PACKAGECONFIG[bluez]   = "--enable-bluez,--disable-bluez,${BLUEZ}"
 PACKAGECONFIG[bz2] = "--enable-bz2,--disable-bz2,bzip2"
@@ -43,13 +48,17 @@ PACKAGECONFIG[faad]= 
"--enable-faad,--disable-faad,faad2"
 PACKAGECONFIG[flite]   = "--enable-flite,--disable-flite,flite-alsa"
 PACKAGECONFIG[fluidsynth]  = 
"--enable-fluidsynth,--disable-fluidsynth,fluidsynth"
 PACKAGECONFIG[hls] = "--enable-hls 
--with-hls-crypto=nettle,--disable-hls,nettle"
+PACKAGECONFIG[gl]  = "--enable-gl,--disable-gl,"
 PACKAGECONFIG[kms] = "--enable-kms,--disable-kms,libdrm"
+PACKAGECONFIG[libde265]= 
"--enable-libde265,--disable-libde265,libde265"
 PACKAGECONFIG[libmms]  = "--enable-libmms,--disable-libmms,libmms"
 PACKAGECONFIG[libssh2] = "--enable-libssh2,--disable-libssh2,libssh2"
+PACKAGECONFIG[lcms2]   = "--enable-lcms2,--disable-lcms2,lcms"
 PACKAGECONFIG[modplug] = 
"--enable-modplug,--disable-modplug,libmodplug"
 PACKAGECONFIG[neon]= "--enable-neon,--disable-neon,neon"
 PACKAGECONFIG[openal]  = "--enable-openal,--disable-openal,openal-soft"
 PACKAGECONFIG[opencv]  = "--enable-opencv,--disable-opencv,opencv"
+PACKAGECONFIG[openh264]= 
"--enable-openh264,--disable-openh264,openh264"
 PACKAGECONFIG[openjpeg]= 
"--enable-openjpeg,--disable-openjpeg,openjpeg"
 # the opus encoder/decoder elements are now in the -base package,
 # but the opus parser remains in -bad
@@ -61,28 +70,34 @@ PACKAGECONFIG[sbc] = 
"--enable-sbc,--disable-sbc,sbc"
 PACKAGECONFIG[smoothstreaming] = 
"--enable-smoothstreaming,--disable-smoothstreaming,libxml2"
 PACKAGECONFIG[sndfile] = 
"--enable-sndfile,--disable-sndfile,libsndfile1"
 PACKAGECONFIG[srtp]= "--enable-srtp,--disable-srtp,libsrtp"
+PACKAGECONFIG[tinyalsa]= 
"--enable-tinyalsa,--disable-tinyalsa,tinyalsa"
+PACKAGECONFIG[ttml]= "--enable-ttml,--disable-ttml,libxml2 pango 
cairo"
 PACKAGECONFIG[uvch264] = "--enable-uvch264,--disable-uvch264,libusb1 
libgudev"
 PACKAGECONFIG[voaacenc]= 
"--enable-voaacenc,--disable-voaacenc,vo-aacenc"
 PACKAGECONFIG[voamrwbenc]  = 
"--enable-voamrwbenc,--disable-voamrwbenc,vo-amrwbenc"
 PACKAGECONFIG[vulkan]  = "--enable-vulkan,--disable-vulkan,vulkan"
 PACKAGECONFIG[wayland] = 
"--enable-wayland,--disable-wayland,wayland-native wayland wayland-protocols 
libdrm"
 PACKAGECONFIG[webp]= "--enable-webp,--disable-webp,libwebp"
+PACKAGECONFIG[webrtc]  = "--enable-webrtc,--disable-webrtc,libnice"
+PACKAGECONFIG[webrtcdsp]   = 
"--enable-webrtcdsp,--disable-webrtcdsp,webrtc-audio-processing"
 
 # these plugins have no corresponding library in OE-core or meta-openembedded:
 #   openni2 winks direct3d directsound winscreencap acm apple_media iqa
-#   android_media avc bs2b chromaprint daala dts fdkaac gme gsm kate ladspa 
libde265
-#   lv2 mpeg2enc mplex msdk musepack nvenc ofa openh264 opensles soundtouch 
spandsp
-#   spc teletextdec tinyalsa vdpau wasapi x265 zbar webrtcdsp
+#   android_media avc bs2b chromaprint daala dts fdkaac gme gsm kate ladspa
+#   lv2 mpeg2enc mplex msdk musepack nvenc ofa openmpt opensles soundtouch
+#   spandsp spc teletextdec vdpau wasapi x265 zbar
 
 

[OE-core] [PATCH v5 2/6] gstreamer1.0-plugin-good: Update packageconfigs

2018-07-24 Thread Carlos Rafael Giani
* There is no twolame recipe in oe-core or in meta-openembedded, so
  disable it
* Reorder the packageconfigs alphabetically

Signed-off-by: Carlos Rafael Giani 
---
 .../gstreamer/gstreamer1.0-plugins-good_1.14.1.bb   | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git 
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.14.1.bb 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.14.1.bb
index 673bf10918..b80cd129be 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.14.1.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.14.1.bb
@@ -27,20 +27,24 @@ inherit gettext
 PACKAGECONFIG ??= " \
 ${GSTREAMER_ORC} \
 ${@bb.utils.filter('DISTRO_FEATURES', 'pulseaudio x11', d)} \
-cairo flac gdk-pixbuf gudev jpeg libpng soup speex taglib v4l2 bz2 zlib 
mpg123 lame \
+bz2 cairo flac gdk-pixbuf gudev jpeg lame libpng mpg123 soup speex taglib 
v4l2 zlib \
 "
 
 X11DEPENDS = "virtual/libx11 libsm libxrender libxfixes libxdamage"
 
+PACKAGECONFIG[bz2]= "--enable-bz2,--disable-bz2,bzip2"
 PACKAGECONFIG[cairo]  = "--enable-cairo,--disable-cairo,cairo"
 PACKAGECONFIG[dv1394] = "--enable-dv1394,--disable-dv1394,libiec61883 
libavc1394 libraw1394"
 PACKAGECONFIG[flac]   = "--enable-flac,--disable-flac,flac"
 PACKAGECONFIG[gdk-pixbuf] = 
"--enable-gdk_pixbuf,--disable-gdk_pixbuf,gdk-pixbuf"
+PACKAGECONFIG[gtk]= "--enable-gtk3,--disable-gtk3,gtk+3"
 PACKAGECONFIG[gudev]  = "--with-gudev,--without-gudev,libgudev"
 PACKAGECONFIG[jack]   = "--enable-jack,--disable-jack,jack"
 PACKAGECONFIG[jpeg]   = "--enable-jpeg,--disable-jpeg,jpeg"
+PACKAGECONFIG[lame]   = "--enable-lame,--disable-lame,lame"
 PACKAGECONFIG[libpng] = "--enable-libpng,--disable-libpng,libpng"
 PACKAGECONFIG[libv4l2]= "--with-libv4l2,--without-libv4l2,v4l-utils"
+PACKAGECONFIG[mpg123] = "--enable-mpg123,--disable-mpg123,mpg123"
 PACKAGECONFIG[pulseaudio] = "--enable-pulse,--disable-pulse,pulseaudio"
 PACKAGECONFIG[soup]   = "--enable-soup,--disable-soup,libsoup-2.4"
 PACKAGECONFIG[speex]  = "--enable-speex,--disable-speex,speex"
@@ -49,11 +53,7 @@ PACKAGECONFIG[v4l2]   = "--enable-gst_v4l2 
--enable-v4l2-probe,--disable-gst
 PACKAGECONFIG[vpx]= "--enable-vpx,--disable-vpx,libvpx"
 PACKAGECONFIG[wavpack]= "--enable-wavpack,--disable-wavpack,wavpack"
 PACKAGECONFIG[x11]= "--enable-x,--disable-x,${X11DEPENDS}"
-PACKAGECONFIG[bz2]= "--enable-bz2,--disable-bz2,bzip2"
 PACKAGECONFIG[zlib]   = "--enable-zlib,--disable-zlib,zlib"
-PACKAGECONFIG[lame]   = "--enable-lame,--disable-lame,lame"
-PACKAGECONFIG[mpg123] = "--enable-mpg123,--disable-mpg123,mpg123"
-PACKAGECONFIG[gtk]= "--enable-gtk3,--disable-gtk3,gtk+3"
 
 # qt5 support is disabled, because it is not present in OE core, and requires 
more work than
 # just adding a packageconfig (it requires access to moc, uic, rcc, and qmake 
paths).
@@ -70,9 +70,10 @@ EXTRA_OECONF += " \
 --disable-oss4 \
 --disable-osx_audio \
 --disable-osx_video \
+--disable-qt \
 --disable-shout2 \
+--disable-twolame \
 --disable-waveform \
---disable-qt \
 "
 
 FILES_${PN}-equalizer += "${datadir}/gstreamer-1.0/presets/*.prs"
-- 
2.17.1

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


Re: [OE-core] [PATCH] lsof: Update SRC_URI

2018-07-24 Thread Alexander Kanavin
Also, if an upgrade is undesirable for some reason, then such changes
need UPSTREAM_CHECK_URI, or we'll be missing new upstream releases.

Alex

2018-07-24 10:07 GMT+02:00 Burton, Ross :
> Well for master if there's a new version then a better fix would be to
> upgrade, but we do need to make sure the previous releases are using
> mirrors.
>
> On 24 July 2018 at 08:48, Ovidiu Panait  wrote:
>> lsof 4.89 archive has been moved to OLD directory and turned into tar.gz,
>> so update SRC_URI and checksums.
>>
>> Signed-off-by: Ovidiu Panait 
>> ---
>>  meta/recipes-extended/lsof/lsof_4.89.bb | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/meta/recipes-extended/lsof/lsof_4.89.bb 
>> b/meta/recipes-extended/lsof/lsof_4.89.bb
>> index 14546db23c..b58b8281f9 100644
>> --- a/meta/recipes-extended/lsof/lsof_4.89.bb
>> +++ b/meta/recipes-extended/lsof/lsof_4.89.bb
>> @@ -11,12 +11,12 @@ LIC_FILES_CHKSUM = 
>> "file://00README;beginline=645;endline=679;md5=964df275d26429
>>  # https://people.freebsd.org/~abe/ ). http://www.mirrorservice.org seems to 
>> be
>>  # the most commonly used alternative.
>>
>> -SRC_URI = 
>> "http://www.mirrorservice.org/sites/lsof.itap.purdue.edu/pub/tools/unix/lsof/lsof_${PV}.tar.bz2
>>  \
>> +SRC_URI = 
>> "http://www.mirrorservice.org/sites/lsof.itap.purdue.edu/pub/tools/unix/lsof/OLD/lsof_${PV}.tar.gz
>>  \
>> file://lsof-remove-host-information.patch \
>>"
>>
>> -SRC_URI[md5sum] = "1b9cd34f3fb86856a125abbf2be3a386"
>> -SRC_URI[sha256sum] = 
>> "81ac2fc5fdc944793baf41a14002b6deb5a29096b387744e28f8c30a360a3718"
>> +SRC_URI[md5sum] = "8afbaff3ee308edc130bdc5df0801c8f"
>> +SRC_URI[sha256sum] = 
>> "5d08da7ebe049c9d9a6472d6afb81aa5af54c4733a3f8822cbc22b57867633c9"
>>
>>  LOCALSRC = "file://${WORKDIR}/lsof_${PV}/lsof_${PV}_src.tar"
>>
>> --
>> 2.17.1
>>
>> --
>> ___
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] coreutils: fix compile error since use wrong libnss_nis.so

2018-07-24 Thread Robert Yang

Hi RP,

On 07/09/2018 04:46 PM, Richard Purdie wrote:

On Mon, 2018-07-09 at 15:49 +0800, changqing...@windriver.com wrote:

From: Changqing Li 

id: relocation error: /lib/x86_64-linux-gnu/libnss_nis.so.2:
symbol _nsl_default_nss version GLIBC_PRIVATE not defined in
file libnsl.so.1 with link time reference

Recent glibc change removed libnss-nis module from glibc and
a new recipe libnss-nis.bb was added. After this change,
we need to include native libnss_nis in coreutils. otherwise,
with "nis" in host /etc/nssswitch.conf, id will use host
libnss_nis.so, which will cause above error

Signed-off-by: Changqing Li 
---
  meta/recipes-core/coreutils/coreutils_8.29.bb | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)


I think this would be fixed by a new version of uninative-tarball after
the recent change to include libnss-nis in it. We should probably have
a new release of uninative rather than starting to add these DEPENDS
everywhere...


When do you plan to rebuild uninative-tarball, please ? I can help if needed.

// Robert



Cheers,

Richard


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


Re: [OE-core] [PATCH] lsof: Update SRC_URI

2018-07-24 Thread Burton, Ross
Well for master if there's a new version then a better fix would be to
upgrade, but we do need to make sure the previous releases are using
mirrors.

On 24 July 2018 at 08:48, Ovidiu Panait  wrote:
> lsof 4.89 archive has been moved to OLD directory and turned into tar.gz,
> so update SRC_URI and checksums.
>
> Signed-off-by: Ovidiu Panait 
> ---
>  meta/recipes-extended/lsof/lsof_4.89.bb | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/meta/recipes-extended/lsof/lsof_4.89.bb 
> b/meta/recipes-extended/lsof/lsof_4.89.bb
> index 14546db23c..b58b8281f9 100644
> --- a/meta/recipes-extended/lsof/lsof_4.89.bb
> +++ b/meta/recipes-extended/lsof/lsof_4.89.bb
> @@ -11,12 +11,12 @@ LIC_FILES_CHKSUM = 
> "file://00README;beginline=645;endline=679;md5=964df275d26429
>  # https://people.freebsd.org/~abe/ ). http://www.mirrorservice.org seems to 
> be
>  # the most commonly used alternative.
>
> -SRC_URI = 
> "http://www.mirrorservice.org/sites/lsof.itap.purdue.edu/pub/tools/unix/lsof/lsof_${PV}.tar.bz2
>  \
> +SRC_URI = 
> "http://www.mirrorservice.org/sites/lsof.itap.purdue.edu/pub/tools/unix/lsof/OLD/lsof_${PV}.tar.gz
>  \
> file://lsof-remove-host-information.patch \
>"
>
> -SRC_URI[md5sum] = "1b9cd34f3fb86856a125abbf2be3a386"
> -SRC_URI[sha256sum] = 
> "81ac2fc5fdc944793baf41a14002b6deb5a29096b387744e28f8c30a360a3718"
> +SRC_URI[md5sum] = "8afbaff3ee308edc130bdc5df0801c8f"
> +SRC_URI[sha256sum] = 
> "5d08da7ebe049c9d9a6472d6afb81aa5af54c4733a3f8822cbc22b57867633c9"
>
>  LOCALSRC = "file://${WORKDIR}/lsof_${PV}/lsof_${PV}_src.tar"
>
> --
> 2.17.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] defaultsetup.conf: Enable security flags+pie by default

2018-07-24 Thread ChenQi

Hi Khem,

The comments in security-flags.inc also needs to be modified to remove 
'poky-lsb' info.


I'd suggest we still put it into distro conf file (poky.conf) instead of 
defaultsetup.conf, because defaultsetup.conf is included by 
bitbake.conf. I think things in defaultsetup.conf should be necessary 
default values to build things out. I don't think security flags is 
necessary to build things out.


Also, I got a question when I just looked at this file.
Do you think we should adjust CFLAGS and LDFALGS in security_flags.inc 
instead of the current TARGET_CC_ARCH and TARGET_LDFLAGS? We are naming 
variables to SECURITY_CFLAGS and SECURITY_LDFLAGS, it seems that they 
belong to CFLAGS and LDFLAGS naturally. But I'm not sure about it.


Best Regards,
Chen Qi


On 07/24/2018 03:09 AM, Khem Raj wrote:

This has been an opt-in for so long, some distributions e.g.
poky-lsb uses it by default however, since most of linux
distros have started to default to these settings for security
enhancements, time has come for OE to make it default too

Signed-off-by: Khem Raj 
---
  meta/conf/distro/defaultsetup.conf | 1 +
  1 file changed, 1 insertion(+)

diff --git a/meta/conf/distro/defaultsetup.conf 
b/meta/conf/distro/defaultsetup.conf
index ca2f9178d2..352e279596 100644
--- a/meta/conf/distro/defaultsetup.conf
+++ b/meta/conf/distro/defaultsetup.conf
@@ -1,6 +1,7 @@
  include conf/distro/include/default-providers.inc
  include conf/distro/include/default-versions.inc
  include conf/distro/include/default-distrovars.inc
+require conf/distro/include/security_flags.inc
  include conf/distro/include/world-broken.inc
  
  TCMODE ?= "default"



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


Re: [OE-core] [PATCH] defaultsetup.conf: Enable security flags+pie by default

2018-07-24 Thread Anuj Mittal
On 07/24/2018 03:09 AM, Khem Raj wrote:
> This has been an opt-in for so long, some distributions e.g.
> poky-lsb uses it by default however, since most of linux
> distros have started to default to these settings for security
> enhancements, time has come for OE to make it default too

Should be removed from poky-lsb in that case otherwise gives duplicate
inclusion warnings.

> 
> Signed-off-by: Khem Raj 
> ---
>  meta/conf/distro/defaultsetup.conf | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/meta/conf/distro/defaultsetup.conf 
> b/meta/conf/distro/defaultsetup.conf
> index ca2f9178d2..352e279596 100644
> --- a/meta/conf/distro/defaultsetup.conf
> +++ b/meta/conf/distro/defaultsetup.conf
> @@ -1,6 +1,7 @@
>  include conf/distro/include/default-providers.inc
>  include conf/distro/include/default-versions.inc
>  include conf/distro/include/default-distrovars.inc
> +require conf/distro/include/security_flags.inc
>  include conf/distro/include/world-broken.inc
>  
>  TCMODE ?= "default"
> 

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