[yocto] [meta-mingw][PATCH] Remove security flags from GCCPIE

[Samuli Piippo]

GCCPIE defaults to "--enable-default-pie" in security_flags.inc,
which breaks Windows binaries.

Signed-off-by: Samuli Piippo 
---
 conf/machine-sdk/include/mingw32-common.inc | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/conf/machine-sdk/include/mingw32-common.inc 
b/conf/machine-sdk/include/mingw32-common.inc
index 92bd184..cd56380 100644
--- a/conf/machine-sdk/include/mingw32-common.inc
+++ b/conf/machine-sdk/include/mingw32-common.inc
@@ -38,3 +38,6 @@ BB_HASHBASE_WHITELIST_append = " WINDRES RC"
 
 # Needed to override no-static-libs.inc
 DISABLE_STATIC_mingw32 = ""
+
+# disable security flags
+GCCPIE_mingw32 = ""
-- 
2.17.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-mingw][PATCH 1/2] winpthreads: use posix threads library from mingw64

[Samuli Piippo]

2/2 is also unrelated, there should 3 patches from me, sent at the same time. 
Don’t know where they got stuck.

> On 15 Nov 2018, at 19.21, Burton, Ross  wrote:
> 
> I see 1/2 but no 2/2, presumably this missing patch is the PIE one?
> 
> Ross
>> On Thu, 15 Nov 2018 at 16:04, Samuli Piippo  wrote:
>> 
>> Use the winpthreads library available in the mingw64 and
>> change the thread model from win32 to posix to get access
>> to c++11 features.
>> 
>> Signed-off-by: Samuli Piippo 
>> ---
>> conf/machine-sdk/include/mingw32-common.inc   |  2 -
>> recipes-core/gettext/gettext_0.19.%.bbappend  |  5 +-
>> recipes-devtools/gcc/gcc-runtime_%.bbappend   |  2 +-
>> recipes-devtools/gcc/libgcc_%.bbappend|  2 +
>> .../nativesdk-mingw-w64-headers_5.0.3.bb  |  5 ++
>> .../nativesdk-mingw-w64-winpthreads_5.0.3.bb  | 31 
>> .../pthreads-win32/pthreads-win32_2.9.1.bb| 47 ---
>> 7 files changed, 40 insertions(+), 54 deletions(-)
>> create mode 100644 
>> recipes-devtools/mingw-w64/nativesdk-mingw-w64-winpthreads_5.0.3.bb
>> delete mode 100644 recipes-devtools/pthreads-win32/pthreads-win32_2.9.1.bb
>> 
>> diff --git a/conf/machine-sdk/include/mingw32-common.inc 
>> b/conf/machine-sdk/include/mingw32-common.inc
>> index cd56380..733d092 100644
>> --- a/conf/machine-sdk/include/mingw32-common.inc
>> +++ b/conf/machine-sdk/include/mingw32-common.inc
>> @@ -1,8 +1,6 @@
>> SDK_OS = "mingw32"
>> NATIVESDKLIBC = "libc-mingw"
>> 
>> -GCCTHREADS_mingw32 = "win32"
>> -
>> PREFERRED_PROVIDER_virtual/nativesdk-${SDK_PREFIX}libc-for-gcc_mingw32 = 
>> "nativesdk-mingw-w64-runtime"
>> PREFERRED_PROVIDER_virtual/nativesdk-${SDK_PREFIX}libc-initial_mingw32 = 
>> "nativesdk-mingw-w64-runtime"
>> PREFERRED_PROVIDER_virtual/nativesdk-libc = "nativesdk-mingw-w64-runtime"
>> diff --git a/recipes-core/gettext/gettext_0.19.%.bbappend 
>> b/recipes-core/gettext/gettext_0.19.%.bbappend
>> index b26b734..21749f3 100644
>> --- a/recipes-core/gettext/gettext_0.19.%.bbappend
>> +++ b/recipes-core/gettext/gettext_0.19.%.bbappend
>> @@ -1,7 +1,4 @@
>> -DEPENDS_append_mingw32 = " pthreads-win32"
>> -LDFLAGS_prepend_mingw32 = " -lpthread "
>> -
>> -EXTRA_OECONF_append_mingw32 = " --enable-threads=windows --enable-static"
>> +EXTRA_OECONF_append_mingw32 = " --enable-static"
>> 
>> FILESEXTRAPATHS_prepend_mingw32 := "${THISDIR}/${BPN}:"
>> SRC_URI_append_mingw32 = " \
>> diff --git a/recipes-devtools/gcc/gcc-runtime_%.bbappend 
>> b/recipes-devtools/gcc/gcc-runtime_%.bbappend
>> index 1641cb9..f14edf1 100644
>> --- a/recipes-devtools/gcc/gcc-runtime_%.bbappend
>> +++ b/recipes-devtools/gcc/gcc-runtime_%.bbappend
>> @@ -11,4 +11,4 @@ RUNTIMETARGET_remove_mingw32 = "libitm"
>> # mingw builds
>> RUNTIMETARGET_remove_mingw32 = "libmpx"
>> 
>> -DEPENDS_append_mingw32 = " pthreads-win32"
>> +DEPENDS_append_mingw32 = " nativesdk-mingw-w64-winpthreads"
>> diff --git a/recipes-devtools/gcc/libgcc_%.bbappend 
>> b/recipes-devtools/gcc/libgcc_%.bbappend
>> index 2a95d02..f542cfc 100644
>> --- a/recipes-devtools/gcc/libgcc_%.bbappend
>> +++ b/recipes-devtools/gcc/libgcc_%.bbappend
>> @@ -1,3 +1,5 @@
>> +DEPENDS_append_mingw32 = " nativesdk-mingw-w64-winpthreads"
>> +
>> FILES_${PN}_append_mingw32 = " ${bindir}/libgcc*.dll"
>> FILES_${PN}-dev_append_mingw32 = " ${base_libdir}/libgcc*.a"
>> 
>> diff --git a/recipes-devtools/mingw-w64/nativesdk-mingw-w64-headers_5.0.3.bb 
>> b/recipes-devtools/mingw-w64/nativesdk-mingw-w64-headers_5.0.3.bb
>> index e129c32..009e5af 100644
>> --- a/recipes-devtools/mingw-w64/nativesdk-mingw-w64-headers_5.0.3.bb
>> +++ b/recipes-devtools/mingw-w64/nativesdk-mingw-w64-headers_5.0.3.bb
>> @@ -31,4 +31,9 @@ do_compile() {
>>:
>> }
>> 
>> +do_install_append() {
>> +# install correct pthread headers
>> +install -m 0644 -t ${D}${includedir} 
>> ${S}/../mingw-w64-libraries/winpthreads/include/*.h
>> +}
>> +
>> FILES_${PN} += "${exec_prefix}/${TARGET_SYS}"
>> diff --git 
>> a/recipes-devtools/mingw-w64/nativesdk-mingw-w64-winpthreads_5.0.3.bb 
>> b/recipes-devtools/mingw-w64/nativesdk-mingw-w64-winpthreads_5.0.3.bb
>> new file mode 100644
>> index 000..1308760
>> --- /dev/null
>> +++ b/recipes-devtools/mingw-w64/nativesdk-mingw-w64-winpthreads_5.0.3.bb
>> @@ -0,0 +1,31 @@
>> +DESCRIPTION = "Winpthreads runtime libraries from MinGW-w64 project"
>> +LICENSE = "ZPL-2.1"
>> +LIC_FILES_CHKSUM = 
>> "file://../../COPYING;md5=bb936f0e04d8f1e19ad545100cee9654"
>> +
>> +COMPATIBLE_HOST = ".*-mingw.*"
>> +
>> +SRC_URI = 
>> "${SOURCEFORGE_MIRROR}/project/mingw-w64/mingw-w64/mingw-w64-release/mingw-w64-v${PV}.tar.bz2"
>> +SRC_URI[md5sum] = "5524c20312560cc8683b7d8ee292cb8c"
>> +SRC_URI[sha256sum] = 
>> "2a601db99ef579b9be69c775218ad956a24a09d7dabc9ff6c5bd60da9ccc9cb4"
>> +
>> +S = "${WORKDIR}/mingw-w64-v${PV}/mingw-w64-libraries/winpthreads"
>> +B = "${WORKDIR}/build-${TARGET_SYS}"
>> +
>> +inherit autotools nativesdk
>> +
>> +INHIBIT_DEFAULT_DEPS = "1"
>> +DEPENDS = "nativesdk-mingw-w64-runtime 

Re: [yocto] [meta-mingw][PATCH 2/2] cmake: add support for building nativesdk-cmake

[Joshua Watt]

On Thu, Nov 15, 2018 at 7:22 PM Samuli Piippo  wrote:
>
> Build nativesdk-cmake and dependency libs without without openssl.
>
> Signed-off-by: Samuli Piippo 
> ---
>  .../nativesdk-packagegroup-sdk-host.bbappend  | 1 +
>  recipes-devtools/cmake/cmake_%.bbappend   | 8 
>  recipes-extended/libarchive/libarchive_%.bbappend | 1 +
>  recipes-support/curl/curl_%.bbappend  | 2 ++
>  4 files changed, 12 insertions(+)
>  create mode 100644 recipes-devtools/cmake/cmake_%.bbappend
>  create mode 100644 recipes-extended/libarchive/libarchive_%.bbappend
>  create mode 100644 recipes-support/curl/curl_%.bbappend
>
> diff --git 
> a/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bbappend 
> b/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bbappend
> index ad69b13..9544ffb 100644
> --- a/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bbappend
> +++ b/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bbappend
> @@ -2,4 +2,5 @@ RDEPENDS_${PN}_mingw32 = "\
>  nativesdk-pkgconfig \
>  nativesdk-libtool \
>  nativesdk-qemu \
> +nativesdk-cmake \

Have you been successful at getting cmake to work properly in MinGW?
I've been working on automated tests for the SDK, and for kicks I
pulled in your changes and tried to write a test for cmake (heavily
borrowed from the cmake/assimp test in oe-core). When I ran the test,
I got the following:

--- snip ---

-- Building for: NMake Makefiles
-- The C compiler identification is GNU 8.2.0
CMake Error at 
Z:/projects/poky/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/testimage-sdk/CMakeTest-zljaq7x7/build/CMakeFiles/3.12.2/CMakeCCompiler.cmake:2
(set):
  Syntax error in cmake code at


Z:/projects/poky/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/testimage-sdk/CMakeTest-zljaq7x7/build/CMakeFiles/3.12.2/CMakeCCompiler.cmake:2

  when parsing string

  -m32 -march=i586
--sysroot=Z:\projects\poky\build\tmp\work\QEMU~ELC\CORE~B5D\1N25.0-R\TEST~Y0Z\\sysroots\i586-poky-linux

  Invalid escape sequence \p
Call Stack (most recent call first):
  CMakeLists.txt:38 (PROJECT)

--- snip ---

It looks like cmake doesn't like the Windows style slashes in CFLAGS.

You can see my test branch at jpew/oeqa in meta-mingw-contrib... it's
still in progress so it might be a bit of work if you want to try it
yourself.

>  "
> diff --git a/recipes-devtools/cmake/cmake_%.bbappend 
> b/recipes-devtools/cmake/cmake_%.bbappend
> new file mode 100644
> index 000..f76cd82
> --- /dev/null
> +++ b/recipes-devtools/cmake/cmake_%.bbappend
> @@ -0,0 +1,8 @@
> +DEPENDS_remove_mingw32 = "ncurses"
> +
> +cmake_do_generate_toolchain_file_append_mingw32() {
> +cat >> ${WORKDIR}/toolchain.cmake < +set( CMAKE_SYSTEM_NAME Windows )
> +EOF
> +}
> +
> diff --git a/recipes-extended/libarchive/libarchive_%.bbappend 
> b/recipes-extended/libarchive/libarchive_%.bbappend
> new file mode 100644
> index 000..a411b40
> --- /dev/null
> +++ b/recipes-extended/libarchive/libarchive_%.bbappend
> @@ -0,0 +1 @@
> +EXTRA_OECONF_append_mingw32 = " --without-cng"
> diff --git a/recipes-support/curl/curl_%.bbappend 
> b/recipes-support/curl/curl_%.bbappend
> new file mode 100644
> index 000..7865b46
> --- /dev/null
> +++ b/recipes-support/curl/curl_%.bbappend
> @@ -0,0 +1,2 @@
> +PACKAGECONFIG_remove_class-nativesdk_mingw32 = "ssl"
> +RRECOMMENDS_lib${BPN}_remove_mingw32 = "ca-certificates"
> --
> 2.17.1
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-mingw][PATCH 1/2] winpthreads: use posix threads library from mingw64

[Samuli Piippo]

Sure, it’ll take me couple of hours though.
Let’s see if the missing emails appear meanwhile.

> On 15 Nov 2018, at 19.33, Burton, Ross  wrote:
> 
> Weird.
> 
> Can you push them to a git repo?
> 
> Ross
>> On Thu, 15 Nov 2018 at 17:32, Samuli Piippo  wrote:
>> 
>> 
>> 2/2 is also unrelated, there should 3 patches from me, sent at the same 
>> time. Don’t know where they got stuck.
>> 
>>> On 15 Nov 2018, at 19.21, Burton, Ross  wrote:
>>> 
>>> I see 1/2 but no 2/2, presumably this missing patch is the PIE one?
>>> 
>>> Ross
 On Thu, 15 Nov 2018 at 16:04, Samuli Piippo  wrote:
 
 Use the winpthreads library available in the mingw64 and
 change the thread model from win32 to posix to get access
 to c++11 features.
 
 Signed-off-by: Samuli Piippo 
 ---
 conf/machine-sdk/include/mingw32-common.inc   |  2 -
 recipes-core/gettext/gettext_0.19.%.bbappend  |  5 +-
 recipes-devtools/gcc/gcc-runtime_%.bbappend   |  2 +-
 recipes-devtools/gcc/libgcc_%.bbappend|  2 +
 .../nativesdk-mingw-w64-headers_5.0.3.bb  |  5 ++
 .../nativesdk-mingw-w64-winpthreads_5.0.3.bb  | 31 
 .../pthreads-win32/pthreads-win32_2.9.1.bb| 47 ---
 7 files changed, 40 insertions(+), 54 deletions(-)
 create mode 100644 
 recipes-devtools/mingw-w64/nativesdk-mingw-w64-winpthreads_5.0.3.bb
 delete mode 100644 recipes-devtools/pthreads-win32/pthreads-win32_2.9.1.bb
 
 diff --git a/conf/machine-sdk/include/mingw32-common.inc 
 b/conf/machine-sdk/include/mingw32-common.inc
 index cd56380..733d092 100644
 --- a/conf/machine-sdk/include/mingw32-common.inc
 +++ b/conf/machine-sdk/include/mingw32-common.inc
 @@ -1,8 +1,6 @@
 SDK_OS = "mingw32"
 NATIVESDKLIBC = "libc-mingw"
 
 -GCCTHREADS_mingw32 = "win32"
 -
 PREFERRED_PROVIDER_virtual/nativesdk-${SDK_PREFIX}libc-for-gcc_mingw32 = 
 "nativesdk-mingw-w64-runtime"
 PREFERRED_PROVIDER_virtual/nativesdk-${SDK_PREFIX}libc-initial_mingw32 = 
 "nativesdk-mingw-w64-runtime"
 PREFERRED_PROVIDER_virtual/nativesdk-libc = "nativesdk-mingw-w64-runtime"
 diff --git a/recipes-core/gettext/gettext_0.19.%.bbappend 
 b/recipes-core/gettext/gettext_0.19.%.bbappend
 index b26b734..21749f3 100644
 --- a/recipes-core/gettext/gettext_0.19.%.bbappend
 +++ b/recipes-core/gettext/gettext_0.19.%.bbappend
 @@ -1,7 +1,4 @@
 -DEPENDS_append_mingw32 = " pthreads-win32"
 -LDFLAGS_prepend_mingw32 = " -lpthread "
 -
 -EXTRA_OECONF_append_mingw32 = " --enable-threads=windows --enable-static"
 +EXTRA_OECONF_append_mingw32 = " --enable-static"
 
 FILESEXTRAPATHS_prepend_mingw32 := "${THISDIR}/${BPN}:"
 SRC_URI_append_mingw32 = " \
 diff --git a/recipes-devtools/gcc/gcc-runtime_%.bbappend 
 b/recipes-devtools/gcc/gcc-runtime_%.bbappend
 index 1641cb9..f14edf1 100644
 --- a/recipes-devtools/gcc/gcc-runtime_%.bbappend
 +++ b/recipes-devtools/gcc/gcc-runtime_%.bbappend
 @@ -11,4 +11,4 @@ RUNTIMETARGET_remove_mingw32 = "libitm"
 # mingw builds
 RUNTIMETARGET_remove_mingw32 = "libmpx"
 
 -DEPENDS_append_mingw32 = " pthreads-win32"
 +DEPENDS_append_mingw32 = " nativesdk-mingw-w64-winpthreads"
 diff --git a/recipes-devtools/gcc/libgcc_%.bbappend 
 b/recipes-devtools/gcc/libgcc_%.bbappend
 index 2a95d02..f542cfc 100644
 --- a/recipes-devtools/gcc/libgcc_%.bbappend
 +++ b/recipes-devtools/gcc/libgcc_%.bbappend
 @@ -1,3 +1,5 @@
 +DEPENDS_append_mingw32 = " nativesdk-mingw-w64-winpthreads"
 +
 FILES_${PN}_append_mingw32 = " ${bindir}/libgcc*.dll"
 FILES_${PN}-dev_append_mingw32 = " ${base_libdir}/libgcc*.a"
 
 diff --git 
 a/recipes-devtools/mingw-w64/nativesdk-mingw-w64-headers_5.0.3.bb 
 b/recipes-devtools/mingw-w64/nativesdk-mingw-w64-headers_5.0.3.bb
 index e129c32..009e5af 100644
 --- a/recipes-devtools/mingw-w64/nativesdk-mingw-w64-headers_5.0.3.bb
 +++ b/recipes-devtools/mingw-w64/nativesdk-mingw-w64-headers_5.0.3.bb
 @@ -31,4 +31,9 @@ do_compile() {
   :
 }
 
 +do_install_append() {
 +# install correct pthread headers
 +install -m 0644 -t ${D}${includedir} 
 ${S}/../mingw-w64-libraries/winpthreads/include/*.h
 +}
 +
 FILES_${PN} += "${exec_prefix}/${TARGET_SYS}"
 diff --git 
 a/recipes-devtools/mingw-w64/nativesdk-mingw-w64-winpthreads_5.0.3.bb 
 b/recipes-devtools/mingw-w64/nativesdk-mingw-w64-winpthreads_5.0.3.bb
 new file mode 100644
 index 000..1308760
 --- /dev/null
 +++ b/recipes-devtools/mingw-w64/nativesdk-mingw-w64-winpthreads_5.0.3.bb
 @@ -0,0 +1,31 @@
 +DESCRIPTION = "Winpthreads runtime libraries from MinGW-w64 project"
 +LICENSE = "ZPL-2.1"
 +LIC_FILES_CHKSUM = 
 "file://../../COPYING;md5=bb936f0e04d8f1e19ad545100cee9654"
 +
 +COMPATIBLE_HOST = ".*-mingw.*"
 +

[yocto] [meta-mingw][PATCH 2/2] cmake: add support for building nativesdk-cmake

[Samuli Piippo]

Build nativesdk-cmake and dependency libs without without openssl.

Signed-off-by: Samuli Piippo 
---
 .../nativesdk-packagegroup-sdk-host.bbappend  | 1 +
 recipes-devtools/cmake/cmake_%.bbappend   | 8 
 recipes-extended/libarchive/libarchive_%.bbappend | 1 +
 recipes-support/curl/curl_%.bbappend  | 2 ++
 4 files changed, 12 insertions(+)
 create mode 100644 recipes-devtools/cmake/cmake_%.bbappend
 create mode 100644 recipes-extended/libarchive/libarchive_%.bbappend
 create mode 100644 recipes-support/curl/curl_%.bbappend

diff --git 
a/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bbappend 
b/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bbappend
index ad69b13..9544ffb 100644
--- a/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bbappend
+++ b/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bbappend
@@ -2,4 +2,5 @@ RDEPENDS_${PN}_mingw32 = "\
 nativesdk-pkgconfig \
 nativesdk-libtool \
 nativesdk-qemu \
+nativesdk-cmake \
 "
diff --git a/recipes-devtools/cmake/cmake_%.bbappend 
b/recipes-devtools/cmake/cmake_%.bbappend
new file mode 100644
index 000..f76cd82
--- /dev/null
+++ b/recipes-devtools/cmake/cmake_%.bbappend
@@ -0,0 +1,8 @@
+DEPENDS_remove_mingw32 = "ncurses"
+
+cmake_do_generate_toolchain_file_append_mingw32() {
+cat >> ${WORKDIR}/toolchain.cmake 

[yocto] [ANNOUNCEMENT] Yocto Project 2.6 (thud 20.0.0) Released

[Tracy Graydon]

Hello,

We are pleased to announce the latest release of the Yocto Project 2.6 
(thud-20.0.0) is now available for download at:

http://downloads.yoctoproject.org/releases/yocto/yocto-2.6/poky-thud-20.0.0.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.6/poky-thud-20.0.0.tar.bz2

A gpg signed version of these release notes is available at:

http://downloads.yoctoproject.org/releases/yocto/yocto-2.6/RELEASENOTES

Full pass test report is available at:

https://wiki.yoctoproject.org/wiki/WW44_-_2018-10-30_-_Full_Test_Cycle_2.6_M4_RC1

Thank you for everyone's contributions to this release.

Sincerely,

Tracy Graydon
Yocto Project Build and Release
tracy.gray...@intel.com

---
yocto-2.6 Errata
---
Release Name: bitbake-thud-20.0.0
Branch: 1.40.0
Tag: 1.40.0
Hash: 0cfc71d1a342b82781b0ba547421e41f6340902a
md5: 0076740c69f41349c7799c874172391e
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-2.6/bitbake-thud-20.0.0.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.6/bitbake-thud-20.0.0.tar.bz2

Release Name: eclipse-poky-neon-thud-20.0.0
Branch: thud
Tag: 2018-10
Hash: 303e46a6848f1937d12541a7fd58e61aa1361225
md5: f8ac98038e49fa22be3889291a137d2d
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-2.6/eclipse-poky-neon-thud-20.0.0.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.6/eclipse-poky-neon-thud-20.0.0.tar.bz2

Release Name: eclipse-poky-oxygen-thud-20.0.0
Branch: thud
Tag: 2018-10
Hash: f1a20dc6a5a252a4ed4484b618d579cbbc7d146e
md5: 61fd3f89fc5b7bb21a0adb42939f7787
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-2.6/eclipse-poky-oxygen-thud-20.0.0.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.6/eclipse-poky-oxygen-thud-20.0.0.tar.bz2

Release Name: meta-gplv2-thud-20.0.0
Branch: thud
Tag: thud-20.0.0
Hash: 379ea8dd144b06aeb459e9a82c792c84d8a5baf7
md5: 8eb5e25e99245fcd135f6089011d6b3d
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-2.6/meta-gplv2-thud-20.0.0.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.6/meta-gplv2-thud-20.0.0.tar.bz2

Release Name: meta-intel-thud-20.0.0
Branch: thud
Tag: thud-20.0.0
Hash: 847dcbb866bb48c3a051967dd0b46b452aa9d5c4
md5: ae67136bccf0a9799c51714e5fa8ee31
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-2.6/meta-intel-thud-20.0.0.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.6/meta-intel-thud-20.0.0.tar.bz2

Release Name: meta-mingw-thud-20.0.0
Branch: thud
Tag: thud-20.0.0
Hash: 8ddd31f2dfe506e45f22a6dd67f997045a34804e
md5: 2f32bb5cccee1bd3da40bb6b4e330cd9
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-2.6/meta-mingw-thud-20.0.0.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.6/meta-mingw-thud-20.0.0.tar.bz2

Release Name: meta-qt3-thud-20.0.0
Branch: thud
Tag: thud-20.0.0
Hash: 02f273cba6c25f5cf20cb66d8a417a83772c3179
md5: 7b73bf1132428ea898938b03815cad21
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-2.6/meta-qt3-thud-20.0.0.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.6/meta-qt3-thud-20.0.0.tar.bz2

Release Name: meta-qt4-thud-20.0.0
Branch: thud
Tag: thud-20.0.0
Hash: 8e791c40140460825956430ba86b6266fdec0a93
md5: 54d50515ac648ccfb8dba421705716e5
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-2.6/meta-qt4-thud-20.0.0.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.6/meta-qt4-thud-20.0.0.tar.bz2

Release Name: oecore-thud-20.0.0
Branch: thud
Tag: thud-20.0.0
Hash: 1fd7d0f2fbf7e200844c675ddb77513a8d5d7327
md5: 8fd9580cc86bc3231da4647c6bba5231
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-2.6/oecore-thud-20.0.0.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.6/oecore-thud-20.0.0.tar.bz2

Release Name: poky-thud-20.0.0
Branch: thud
Tag: thud-20.0.0
Hash: 84eecb017ef92ef36b4df730908828e54aeff85c
md5: 0bde045803827b62e53ccc07c7b5b6ad
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-2.6/poky-thud-20.0.0.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.6/poky-thud-20.0.0.tar.bz2


-
New Features / Enhancements
-
* Linux kernel 4.18/4.14, gcc 8.2, glibc 2.28 and ~245 other recipe upgrades
* Enabled security flags+pie by default in poky distribution
* python3: enabled profile-guided optimization for improved runtime performance
* Added support for building newlib as the system C library
* Specific architecture support:
 - Support Synopsys DesignWare ARC architecture (glibc support currently 
requires meta-synopsys)
 - grub-efi: add grub target and image for aarch64
 - Added support for aarch64 hosts in uninative and MACHINE_SDK
 - sysprof: enabled for aarch64
 - linux-yocto: added qemuarm64 preempt-rt BSP definition
 - Added RISC-V support for qemu, nspr, liburcu, meson, and support 
enhancements in various other parts of the build system
 - Added LatticeMico32 

Re: [yocto] QEMU kernel defconfigs

[Scott Rifenbark]

On Thu, Nov 15, 2018 at 12:08 PM Bruce Ashfield <
bruce.ashfi...@windriver.com> wrote:

> On 2018-11-15 12:29 p.m., Jon Mason wrote:
> > I'm having difficulty determining where the kernel defconfigs are
> > defined and located.  I'm specifically looking for the qemuarm and
> > qemuarm64 kernel defconfigs.  I've looked at the relevant
> > documentation,
> https://www.yoctoproject.org/docs/2.5.1/kernel-dev/kernel-dev.html#using-an-in-tree-defconfig-file
> > and
> > no SRC_URI with defconfig or KBUILD_DEFCONFIG_KMACHINE defined in
> > meta/recipes-kernel/linux/linux-yocto_4.18.bb
> >
> > What am I missing?
>
> The reference machines with linux-yocto don't use defconfigs at all.
> They are fully assembled from the configuration fragments in the
> kernel-cache repo.
>
> You'll see the location of the kernel-cache, and the routines that
> gather up the fragments in the linux-yocto* recipes.
>
> The kernel development manual has that detail as well:
>
>
> https://www.yoctoproject.org/docs/2.5.1/kernel-dev/kernel-dev.html#kernel-dev-advanced
>
> Bruce
>
> >
> > Also, "A defconfig file is simply a .config renamed to "defconfig"."
> > is not correct.  A properly created defconfig is created by `make
> > savedefconfig` and is a minimal file which only has the delta between
> > the desired config and defaults from the Kconfig files.
> >
> https://www.yoctoproject.org/docs/2.5.1/kernel-dev/kernel-dev.html#creating-a-defconfig-file
> >
> > Thanks,
> > Jon
>

Jon - see
https://www.yoctoproject.org/docs/2.5.1/kernel-dev/kernel-dev.html#creating-a-defconfig-file
for some re-phrasing.

>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How do I enabled Fortran support in Sumo?

[Mike Worster]

Thanks for your input. Unfortunately adding your suggested line:
RUNTIMETARGET_append_pn-gcc-runtime = " libquadmath"
doesn't seem to change the build error for me.

Odd thing is when I look at the output of the RUNTIMETARGET variable it
doesn't appear to be set:
$ bitbake -e libgfortran | grep "RUNTIMETARGET"
# $RUNTIMETARGET
RUNTIMETARGET=""

On Thu, Nov 15, 2018 at 3:42 PM akuster808  wrote:

>
>
> On 11/15/18 1:31 PM, Mike Worster wrote:
>
> I'm trying to get Fortran support (gfortran and libgfortran) enabled in a
> Yocto Sumo build.
>
> Based on advice I got from this site:
> https://jumpnowtek.com/yocto/Add-Fortran-support-to-a-Yocto-build.html
>
> I have enabled fortran in my local.conf via adding:
>
> FORTRAN_forcevariable = ",fortran"
>
> And I have created a gcc-runtime_7.3.bbappend file containing:
>
> RUNTIMETARGET += "libgfortran"
>
>
> I recently ran into something similar. I ended up using in my local.conf
> FORTRAN_forcevariable = ",fortran"
> RUNTIMETARGET_append_pn-gcc-runtime = " libquadmath" <<<--- maybe key??
>
> and in one recipe I had a depends on "libgfortran" and is seems to build
> fine.
>
> - armin
>
>
> And I have added gfortran to my image:
>
> FORTRAN_TOOLS = " \
> gfortran \
> gfortran-symlinks \
> libgfortran \
> libgfortran-dev \
>  "
>
> IMAGE_INSTALL += " \
> ${FORTRAN_TOOLS} \
>  "
> After all these modifications when I go to build I see the following error:
>
> |
> ../../../../../../../../work-shared/gcc-7.3.0-r0/gcc-7.3.0/libgfortran/runtime/backtrace.c:36:10:
> fatal error: backtrace-supported.h: No such file or directory
> |  #include "backtrace-supported.h"
> |   ^~~
> | compilation terminated.
> | Makefile:2310: recipe for target 'backtrace.lo' failed
> | make[1]: *** [backtrace.lo] Error 1
>
> I've found I can get past this by updating
> poky/meta/recipes-devtools/gcc/gcc-7.3.inc with the following line:
>
> CFLAGS += " -I../../libbacktrace "
>
> The build then dies later here:
>
> | libtool: link: cannot find the library `../libbacktrace/libbacktrace.la'
> or unhandled argument `../libbacktrace/libbacktrace.la'
> | Makefile:1364: recipe for target 'libgfortran.la' failed
> | make[1]: *** [libgfortran.la] Error 1
>
> I can resolve that by adjusting the Makefile found at:
> tmp/work/cortexa9hf-neon-poky-linux-gnueabi/gcc-runtime/7.3.0-r0/gcc-7.3.0/build.arm-poky-linux-gnueabi.arm-poky-linux-gnueabi/arm-poky-linux-gnueabi/libgfortran/Makefile.
> The following adjustment:
>
>  $(LTLDFLAGS) $(LIBQUADLIB) ../../libbacktrace/libbacktrace.la \
>
> gets past the failure to find the library (one directory up). Then running
> the build again, there is the real problem:
>
> | ../../libbacktrace/.libs/libbacktrace.a: member
> ../../libbacktrace/.libs/libbacktrace.a(atomic.o) in archive is not an
> object
> | collect2: error: ld returned 1 exit status
> | ERROR: oe_runmake failed
> | Makefile:1364: recipe for target 'libgfortran.la' failed
> | make[1]: *** [libgfortran.la] Error 1
>
> As far as I can tell, the archive's elements (atomic.o being first) are
> being built for x86 instead of ARM, and thus they are not being recognized
> as objects.
>
> Does anyone have input on this issue? Any ideas why this is broken, or how
> to resolve this?
>
> -Mike
>
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How do I enabled Fortran support in Sumo?

[akuster808]

On 11/15/18 1:31 PM, Mike Worster wrote:
> I'm trying to get Fortran support (gfortran and libgfortran) enabled
> in a Yocto Sumo build.
>
> Based on advice I got from this site:
> https://jumpnowtek.com/yocto/Add-Fortran-support-to-a-Yocto-build.html
>
> I have enabled fortran in my local.conf via adding:
>
>     FORTRAN_forcevariable = ",fortran"
>
> And I have created a gcc-runtime_7.3.bbappend file containing:
>
>     RUNTIMETARGET += "libgfortran"

I recently ran into something similar. I ended up using in my local.conf
FORTRAN_forcevariable = ",fortran"
RUNTIMETARGET_append_pn-gcc-runtime = " libquadmath" <<<--- maybe key??

and in one recipe I had a depends on "libgfortran" and is seems to build
fine.

- armin

>
> And I have added gfortran to my image:
>
>     FORTRAN_TOOLS = " \
>         gfortran \
>     gfortran-symlinks \
>     libgfortran \
>     libgfortran-dev \
>  "
>
>     IMAGE_INSTALL += " \
>         ${FORTRAN_TOOLS} \
>      "
> After all these modifications when I go to build I see the following
> error:
>
> |
> ../../../../../../../../work-shared/gcc-7.3.0-r0/gcc-7.3.0/libgfortran/runtime/backtrace.c:36:10:
> fatal error: backtrace-supported.h: No such file or directory
> |  #include "backtrace-supported.h"
> |   ^~~
> | compilation terminated.
> | Makefile:2310: recipe for target 'backtrace.lo' failed
> | make[1]: *** [backtrace.lo] Error 1
>
> I've found I can get past this by updating
> poky/meta/recipes-devtools/gcc/gcc-7.3.inc with the following line:
>
>     CFLAGS += " -I../../libbacktrace "
>
> The build then dies later here:
>
> | libtool: link: cannot find the library
> `../libbacktrace/libbacktrace.la ' or
> unhandled argument `../libbacktrace/libbacktrace.la
> '
> | Makefile:1364: recipe for target 'libgfortran.la
> ' failed
> | make[1]: *** [libgfortran.la ] Error 1
>
> I can resolve that by adjusting the Makefile found at:
> tmp/work/cortexa9hf-neon-poky-linux-gnueabi/gcc-runtime/7.3.0-r0/gcc-7.3.0/build.arm-poky-linux-gnueabi.arm-poky-linux-gnueabi/arm-poky-linux-gnueabi/libgfortran/Makefile.
> The following adjustment:
>
>  $(LTLDFLAGS) $(LIBQUADLIB) ../../libbacktrace/libbacktrace.la
>  \
>
> gets past the failure to find the library (one directory up). Then
> running the build again, there is the real problem:
>
> | ../../libbacktrace/.libs/libbacktrace.a: member
> ../../libbacktrace/.libs/libbacktrace.a(atomic.o) in archive is not an
> object
> | collect2: error: ld returned 1 exit status
> | ERROR: oe_runmake failed
> | Makefile:1364: recipe for target 'libgfortran.la
> ' failed
> | make[1]: *** [libgfortran.la ] Error 1
>
> As far as I can tell, the archive's elements (atomic.o being first)
> are being built for x86 instead of ARM, and thus they are not being
> recognized as objects.
>
> Does anyone have input on this issue? Any ideas why this is broken, or
> how to resolve this?
>
> -Mike
>

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] How do I enabled Fortran support in Sumo?

[Mike Worster]

I'm trying to get Fortran support (gfortran and libgfortran) enabled in a
Yocto Sumo build.

Based on advice I got from this site:
https://jumpnowtek.com/yocto/Add-Fortran-support-to-a-Yocto-build.html

I have enabled fortran in my local.conf via adding:

FORTRAN_forcevariable = ",fortran"

And I have created a gcc-runtime_7.3.bbappend file containing:

RUNTIMETARGET += "libgfortran"

And I have added gfortran to my image:

FORTRAN_TOOLS = " \
gfortran \
gfortran-symlinks \
libgfortran \
libgfortran-dev \
 "

IMAGE_INSTALL += " \
${FORTRAN_TOOLS} \
 "
After all these modifications when I go to build I see the following error:

|
../../../../../../../../work-shared/gcc-7.3.0-r0/gcc-7.3.0/libgfortran/runtime/backtrace.c:36:10:
fatal error: backtrace-supported.h: No such file or directory
|  #include "backtrace-supported.h"
|   ^~~
| compilation terminated.
| Makefile:2310: recipe for target 'backtrace.lo' failed
| make[1]: *** [backtrace.lo] Error 1

I've found I can get past this by updating
poky/meta/recipes-devtools/gcc/gcc-7.3.inc with the following line:

CFLAGS += " -I../../libbacktrace "

The build then dies later here:

| libtool: link: cannot find the library `../libbacktrace/libbacktrace.la'
or unhandled argument `../libbacktrace/libbacktrace.la'
| Makefile:1364: recipe for target 'libgfortran.la' failed
| make[1]: *** [libgfortran.la] Error 1

I can resolve that by adjusting the Makefile found at:
tmp/work/cortexa9hf-neon-poky-linux-gnueabi/gcc-runtime/7.3.0-r0/gcc-7.3.0/build.arm-poky-linux-gnueabi.arm-poky-linux-gnueabi/arm-poky-linux-gnueabi/libgfortran/Makefile.
The following adjustment:

 $(LTLDFLAGS) $(LIBQUADLIB) ../../libbacktrace/libbacktrace.la \

gets past the failure to find the library (one directory up). Then running
the build again, there is the real problem:

| ../../libbacktrace/.libs/libbacktrace.a: member
../../libbacktrace/.libs/libbacktrace.a(atomic.o) in archive is not an
object
| collect2: error: ld returned 1 exit status
| ERROR: oe_runmake failed
| Makefile:1364: recipe for target 'libgfortran.la' failed
| make[1]: *** [libgfortran.la] Error 1

As far as I can tell, the archive's elements (atomic.o being first) are
being built for x86 instead of ARM, and thus they are not being recognized
as objects.

Does anyone have input on this issue? Any ideas why this is broken, or how
to resolve this?

-Mike
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-mingw][PATCH 1/2] winpthreads: use posix threads library from mingw64

[Samuli Piippo]

I don't have access to the contrib git repo, so pushed them here instead: 
https://github.com/sapiippo/meta-mingw/


From: Samuli Piippo
Sent: 15 November 2018 19:45:29
To: Burton, Ross
Cc: Yocto-mailing-list
Subject: Re: [yocto] [meta-mingw][PATCH 1/2] winpthreads: use posix threads 
library from mingw64

Sure, it’ll take me couple of hours though.
Let’s see if the missing emails appear meanwhile.

> On 15 Nov 2018, at 19.33, Burton, Ross  wrote:
>
> Weird.
>
> Can you push them to a git repo?
>
> Ross
>> On Thu, 15 Nov 2018 at 17:32, Samuli Piippo  wrote:
>>
>>
>> 2/2 is also unrelated, there should 3 patches from me, sent at the same 
>> time. Don’t know where they got stuck.
>>
>>> On 15 Nov 2018, at 19.21, Burton, Ross  wrote:
>>>
>>> I see 1/2 but no 2/2, presumably this missing patch is the PIE one?
>>>
>>> Ross
 On Thu, 15 Nov 2018 at 16:04, Samuli Piippo  wrote:

 Use the winpthreads library available in the mingw64 and
 change the thread model from win32 to posix to get access
 to c++11 features.

 Signed-off-by: Samuli Piippo 
 ---
 conf/machine-sdk/include/mingw32-common.inc   |  2 -
 recipes-core/gettext/gettext_0.19.%.bbappend  |  5 +-
 recipes-devtools/gcc/gcc-runtime_%.bbappend   |  2 +-
 recipes-devtools/gcc/libgcc_%.bbappend|  2 +
 .../nativesdk-mingw-w64-headers_5.0.3.bb  |  5 ++
 .../nativesdk-mingw-w64-winpthreads_5.0.3.bb  | 31 
 .../pthreads-win32/pthreads-win32_2.9.1.bb| 47 ---
 7 files changed, 40 insertions(+), 54 deletions(-)
 create mode 100644 
 recipes-devtools/mingw-w64/nativesdk-mingw-w64-winpthreads_5.0.3.bb
 delete mode 100644 recipes-devtools/pthreads-win32/pthreads-win32_2.9.1.bb

 diff --git a/conf/machine-sdk/include/mingw32-common.inc 
 b/conf/machine-sdk/include/mingw32-common.inc
 index cd56380..733d092 100644
 --- a/conf/machine-sdk/include/mingw32-common.inc
 +++ b/conf/machine-sdk/include/mingw32-common.inc
 @@ -1,8 +1,6 @@
 SDK_OS = "mingw32"
 NATIVESDKLIBC = "libc-mingw"

 -GCCTHREADS_mingw32 = "win32"
 -
 PREFERRED_PROVIDER_virtual/nativesdk-${SDK_PREFIX}libc-for-gcc_mingw32 = 
 "nativesdk-mingw-w64-runtime"
 PREFERRED_PROVIDER_virtual/nativesdk-${SDK_PREFIX}libc-initial_mingw32 = 
 "nativesdk-mingw-w64-runtime"
 PREFERRED_PROVIDER_virtual/nativesdk-libc = "nativesdk-mingw-w64-runtime"
 diff --git a/recipes-core/gettext/gettext_0.19.%.bbappend 
 b/recipes-core/gettext/gettext_0.19.%.bbappend
 index b26b734..21749f3 100644
 --- a/recipes-core/gettext/gettext_0.19.%.bbappend
 +++ b/recipes-core/gettext/gettext_0.19.%.bbappend
 @@ -1,7 +1,4 @@
 -DEPENDS_append_mingw32 = " pthreads-win32"
 -LDFLAGS_prepend_mingw32 = " -lpthread "
 -
 -EXTRA_OECONF_append_mingw32 = " --enable-threads=windows --enable-static"
 +EXTRA_OECONF_append_mingw32 = " --enable-static"

 FILESEXTRAPATHS_prepend_mingw32 := "${THISDIR}/${BPN}:"
 SRC_URI_append_mingw32 = " \
 diff --git a/recipes-devtools/gcc/gcc-runtime_%.bbappend 
 b/recipes-devtools/gcc/gcc-runtime_%.bbappend
 index 1641cb9..f14edf1 100644
 --- a/recipes-devtools/gcc/gcc-runtime_%.bbappend
 +++ b/recipes-devtools/gcc/gcc-runtime_%.bbappend
 @@ -11,4 +11,4 @@ RUNTIMETARGET_remove_mingw32 = "libitm"
 # mingw builds
 RUNTIMETARGET_remove_mingw32 = "libmpx"

 -DEPENDS_append_mingw32 = " pthreads-win32"
 +DEPENDS_append_mingw32 = " nativesdk-mingw-w64-winpthreads"
 diff --git a/recipes-devtools/gcc/libgcc_%.bbappend 
 b/recipes-devtools/gcc/libgcc_%.bbappend
 index 2a95d02..f542cfc 100644
 --- a/recipes-devtools/gcc/libgcc_%.bbappend
 +++ b/recipes-devtools/gcc/libgcc_%.bbappend
 @@ -1,3 +1,5 @@
 +DEPENDS_append_mingw32 = " nativesdk-mingw-w64-winpthreads"
 +
 FILES_${PN}_append_mingw32 = " ${bindir}/libgcc*.dll"
 FILES_${PN}-dev_append_mingw32 = " ${base_libdir}/libgcc*.a"

 diff --git 
 a/recipes-devtools/mingw-w64/nativesdk-mingw-w64-headers_5.0.3.bb 
 b/recipes-devtools/mingw-w64/nativesdk-mingw-w64-headers_5.0.3.bb
 index e129c32..009e5af 100644
 --- a/recipes-devtools/mingw-w64/nativesdk-mingw-w64-headers_5.0.3.bb
 +++ b/recipes-devtools/mingw-w64/nativesdk-mingw-w64-headers_5.0.3.bb
 @@ -31,4 +31,9 @@ do_compile() {
   :
 }

 +do_install_append() {
 +# install correct pthread headers
 +install -m 0644 -t ${D}${includedir} 
 ${S}/../mingw-w64-libraries/winpthreads/include/*.h
 +}
 +
 FILES_${PN} += "${exec_prefix}/${TARGET_SYS}"
 diff --git 
 a/recipes-devtools/mingw-w64/nativesdk-mingw-w64-winpthreads_5.0.3.bb 
 b/recipes-devtools/mingw-w64/nativesdk-mingw-w64-winpthreads_5.0.3.bb
 new file mode 100644
 index 000..1308760
 --- /dev/null
 +++ 

Re: [yocto] QEMU kernel defconfigs

[Bruce Ashfield]

On 2018-11-15 12:29 p.m., Jon Mason wrote:

I'm having difficulty determining where the kernel defconfigs are
defined and located.  I'm specifically looking for the qemuarm and
qemuarm64 kernel defconfigs.  I've looked at the relevant
documentation, 
https://www.yoctoproject.org/docs/2.5.1/kernel-dev/kernel-dev.html#using-an-in-tree-defconfig-file
and
no SRC_URI with defconfig or KBUILD_DEFCONFIG_KMACHINE defined in
meta/recipes-kernel/linux/linux-yocto_4.18.bb

What am I missing?


The reference machines with linux-yocto don't use defconfigs at all.
They are fully assembled from the configuration fragments in the
kernel-cache repo.

You'll see the location of the kernel-cache, and the routines that
gather up the fragments in the linux-yocto* recipes.

The kernel development manual has that detail as well:

https://www.yoctoproject.org/docs/2.5.1/kernel-dev/kernel-dev.html#kernel-dev-advanced

Bruce



Also, "A defconfig file is simply a .config renamed to "defconfig"."
is not correct.  A properly created defconfig is created by `make
savedefconfig` and is a minimal file which only has the delta between
the desired config and defaults from the Kconfig files.
https://www.yoctoproject.org/docs/2.5.1/kernel-dev/kernel-dev.html#creating-a-defconfig-file

Thanks,
Jon



--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-mingw][PATCH 0/4] Add oeqa test cases

[Joshua Watt]

Adds the testing framework for tying tests for the MinGW SDK into the
oeqa SDK test framework. 

The SDK tests can be run using the standard SDK test command:

 bitbake -c testsdk 

All testing is done using Wine in lieu of having access to an actual
Windows machine. Wine is required to be installed on the host machine.

Joshua Watt (4):
  Add SDK test case framework
  Add .gitignore
  classes/toolchain-scripts-mingw32: Update variables
  oeqa/sdkmingw: Add test cases

 .gitignore  |   3 +
 classes/testsdk-mingw.bbclass   | 101 
 classes/toolchain-scripts-mingw32.bbclass   |   4 +-
 conf/machine-sdk/i686-mingw32.conf  |   1 +
 conf/machine-sdk/include/mingw32-common.inc |   6 ++
 conf/machine-sdk/x86_64-mingw32.conf|   1 +
 lib/oeqa/sdkmingw/__init__.py   |   0
 lib/oeqa/sdkmingw/case.py   |  52 ++
 lib/oeqa/sdkmingw/cases/__init__.py |   0
 lib/oeqa/sdkmingw/cases/binutils.py |  57 +++
 lib/oeqa/sdkmingw/cases/gcc.py  |  49 ++
 lib/oeqa/sdkmingw/cases/gdb.py  |  20 
 lib/oeqa/sdkmingw/context.py|  66 +
 lib/oeqa/sdkmingw/files/testsdkmakefile |   4 +
 14 files changed, 363 insertions(+), 1 deletion(-)
 create mode 100644 .gitignore
 create mode 100644 classes/testsdk-mingw.bbclass
 create mode 100644 lib/oeqa/sdkmingw/__init__.py
 create mode 100644 lib/oeqa/sdkmingw/case.py
 create mode 100644 lib/oeqa/sdkmingw/cases/__init__.py
 create mode 100644 lib/oeqa/sdkmingw/cases/binutils.py
 create mode 100644 lib/oeqa/sdkmingw/cases/gcc.py
 create mode 100644 lib/oeqa/sdkmingw/cases/gdb.py
 create mode 100644 lib/oeqa/sdkmingw/context.py
 create mode 100644 lib/oeqa/sdkmingw/files/testsdkmakefile

-- 
2.19.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] meta-mingw: unable to run executables on Windows

[Khem Raj]

Ok, thanks.
On Thu, Nov 15, 2018 at 6:48 AM Mark Hatle  wrote:
>
> On 11/14/18 11:01 PM, Khem Raj wrote:
> > On Wed, Nov 14, 2018 at 8:08 PM Joshua Watt  wrote:
> >>
> >> On Wed, Nov 14, 2018 at 8:41 PM Mark Hatle  
> >> wrote:
> >>>
> >>> On 11/14/18 9:54 AM, Mark Hatle wrote:
>  On 11/13/18 3:56 AM, Samuli Piippo wrote:
> > Hi,
> >
> > I've just upgraded poky and meta-mingw layers from sumo to thud and as 
> > a result
> > a lot of the executables in the toolchain no longer run correctly on 
> > Windows.
> 
>  Which version of windows?
> 
> > I've built meta-toolchain for SDKMACHINE=x86_64-mingw32. From that, 
> > gcc/g++ work
> > fine on Windows 10, but ar, as, objdumb, and others hang for ~30 
> > seconds and
> > exit without any output.
> >
> > Has anyone else seen this?
> 
>  I've run a toolchain made on mingw after sumo, but before thud's 
>  release.  I'll
>  see if I can find a VM and give it a try later today.
> >>>
> >>> I'm running on Windows 7 for my testing (ya, I know old.. but it's what I 
> >>> got.)
> >>>
> >>> Can you try adding the following to your conf/local.conf: GCCPIE_mingw32 
> >>> = ""
> >
> > this will be effective just for SDK and native versions I hope, but in
> > cases if we
> > have this override also applicable for target then this fix is not
> > correct. We have
> > to keep using it for target builds.
>
> The mingw32 override is only present when building -nativesdk- mingw32 
> software.
>  -Not- cross candian and similar.
>
> --Mark
>
> >>>
> >>> I found that the SDK was not working properly here as well, but only 
> >>> binutils.
> >>> The above seems to fix the issue.  (You do have to rebuild your SDK.)
> >>
> >> I also saw this issue on Windows 7, and your described fix corrected
> >> it (Thanks!). On the plus side, the automated SDK testing that I'm
> >> working on discovered it as well (e.g. the tests failed because of
> >> it), which means that the tests are working and should help prevent
> >> issues like this in the future once I get it merged.
> >>
> >>>
>  --Mark
> 
> >>>
> >>> --
> >>> ___
> >>> yocto mailing list
> >>> yocto@yoctoproject.org
> >>> https://lists.yoctoproject.org/listinfo/yocto
> >> --
> >> ___
> >> yocto mailing list
> >> yocto@yoctoproject.org
> >> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-mingw][PATCH 1/2] winpthreads: use posix threads library from mingw64

[Burton, Ross]

Weird.

Can you push them to a git repo?

Ross
On Thu, 15 Nov 2018 at 17:32, Samuli Piippo  wrote:
>
>
> 2/2 is also unrelated, there should 3 patches from me, sent at the same time. 
> Don’t know where they got stuck.
>
> > On 15 Nov 2018, at 19.21, Burton, Ross  wrote:
> >
> > I see 1/2 but no 2/2, presumably this missing patch is the PIE one?
> >
> > Ross
> >> On Thu, 15 Nov 2018 at 16:04, Samuli Piippo  wrote:
> >>
> >> Use the winpthreads library available in the mingw64 and
> >> change the thread model from win32 to posix to get access
> >> to c++11 features.
> >>
> >> Signed-off-by: Samuli Piippo 
> >> ---
> >> conf/machine-sdk/include/mingw32-common.inc   |  2 -
> >> recipes-core/gettext/gettext_0.19.%.bbappend  |  5 +-
> >> recipes-devtools/gcc/gcc-runtime_%.bbappend   |  2 +-
> >> recipes-devtools/gcc/libgcc_%.bbappend|  2 +
> >> .../nativesdk-mingw-w64-headers_5.0.3.bb  |  5 ++
> >> .../nativesdk-mingw-w64-winpthreads_5.0.3.bb  | 31 
> >> .../pthreads-win32/pthreads-win32_2.9.1.bb| 47 ---
> >> 7 files changed, 40 insertions(+), 54 deletions(-)
> >> create mode 100644 
> >> recipes-devtools/mingw-w64/nativesdk-mingw-w64-winpthreads_5.0.3.bb
> >> delete mode 100644 recipes-devtools/pthreads-win32/pthreads-win32_2.9.1.bb
> >>
> >> diff --git a/conf/machine-sdk/include/mingw32-common.inc 
> >> b/conf/machine-sdk/include/mingw32-common.inc
> >> index cd56380..733d092 100644
> >> --- a/conf/machine-sdk/include/mingw32-common.inc
> >> +++ b/conf/machine-sdk/include/mingw32-common.inc
> >> @@ -1,8 +1,6 @@
> >> SDK_OS = "mingw32"
> >> NATIVESDKLIBC = "libc-mingw"
> >>
> >> -GCCTHREADS_mingw32 = "win32"
> >> -
> >> PREFERRED_PROVIDER_virtual/nativesdk-${SDK_PREFIX}libc-for-gcc_mingw32 = 
> >> "nativesdk-mingw-w64-runtime"
> >> PREFERRED_PROVIDER_virtual/nativesdk-${SDK_PREFIX}libc-initial_mingw32 = 
> >> "nativesdk-mingw-w64-runtime"
> >> PREFERRED_PROVIDER_virtual/nativesdk-libc = "nativesdk-mingw-w64-runtime"
> >> diff --git a/recipes-core/gettext/gettext_0.19.%.bbappend 
> >> b/recipes-core/gettext/gettext_0.19.%.bbappend
> >> index b26b734..21749f3 100644
> >> --- a/recipes-core/gettext/gettext_0.19.%.bbappend
> >> +++ b/recipes-core/gettext/gettext_0.19.%.bbappend
> >> @@ -1,7 +1,4 @@
> >> -DEPENDS_append_mingw32 = " pthreads-win32"
> >> -LDFLAGS_prepend_mingw32 = " -lpthread "
> >> -
> >> -EXTRA_OECONF_append_mingw32 = " --enable-threads=windows --enable-static"
> >> +EXTRA_OECONF_append_mingw32 = " --enable-static"
> >>
> >> FILESEXTRAPATHS_prepend_mingw32 := "${THISDIR}/${BPN}:"
> >> SRC_URI_append_mingw32 = " \
> >> diff --git a/recipes-devtools/gcc/gcc-runtime_%.bbappend 
> >> b/recipes-devtools/gcc/gcc-runtime_%.bbappend
> >> index 1641cb9..f14edf1 100644
> >> --- a/recipes-devtools/gcc/gcc-runtime_%.bbappend
> >> +++ b/recipes-devtools/gcc/gcc-runtime_%.bbappend
> >> @@ -11,4 +11,4 @@ RUNTIMETARGET_remove_mingw32 = "libitm"
> >> # mingw builds
> >> RUNTIMETARGET_remove_mingw32 = "libmpx"
> >>
> >> -DEPENDS_append_mingw32 = " pthreads-win32"
> >> +DEPENDS_append_mingw32 = " nativesdk-mingw-w64-winpthreads"
> >> diff --git a/recipes-devtools/gcc/libgcc_%.bbappend 
> >> b/recipes-devtools/gcc/libgcc_%.bbappend
> >> index 2a95d02..f542cfc 100644
> >> --- a/recipes-devtools/gcc/libgcc_%.bbappend
> >> +++ b/recipes-devtools/gcc/libgcc_%.bbappend
> >> @@ -1,3 +1,5 @@
> >> +DEPENDS_append_mingw32 = " nativesdk-mingw-w64-winpthreads"
> >> +
> >> FILES_${PN}_append_mingw32 = " ${bindir}/libgcc*.dll"
> >> FILES_${PN}-dev_append_mingw32 = " ${base_libdir}/libgcc*.a"
> >>
> >> diff --git 
> >> a/recipes-devtools/mingw-w64/nativesdk-mingw-w64-headers_5.0.3.bb 
> >> b/recipes-devtools/mingw-w64/nativesdk-mingw-w64-headers_5.0.3.bb
> >> index e129c32..009e5af 100644
> >> --- a/recipes-devtools/mingw-w64/nativesdk-mingw-w64-headers_5.0.3.bb
> >> +++ b/recipes-devtools/mingw-w64/nativesdk-mingw-w64-headers_5.0.3.bb
> >> @@ -31,4 +31,9 @@ do_compile() {
> >>:
> >> }
> >>
> >> +do_install_append() {
> >> +# install correct pthread headers
> >> +install -m 0644 -t ${D}${includedir} 
> >> ${S}/../mingw-w64-libraries/winpthreads/include/*.h
> >> +}
> >> +
> >> FILES_${PN} += "${exec_prefix}/${TARGET_SYS}"
> >> diff --git 
> >> a/recipes-devtools/mingw-w64/nativesdk-mingw-w64-winpthreads_5.0.3.bb 
> >> b/recipes-devtools/mingw-w64/nativesdk-mingw-w64-winpthreads_5.0.3.bb
> >> new file mode 100644
> >> index 000..1308760
> >> --- /dev/null
> >> +++ b/recipes-devtools/mingw-w64/nativesdk-mingw-w64-winpthreads_5.0.3.bb
> >> @@ -0,0 +1,31 @@
> >> +DESCRIPTION = "Winpthreads runtime libraries from MinGW-w64 project"
> >> +LICENSE = "ZPL-2.1"
> >> +LIC_FILES_CHKSUM = 
> >> "file://../../COPYING;md5=bb936f0e04d8f1e19ad545100cee9654"
> >> +
> >> +COMPATIBLE_HOST = ".*-mingw.*"
> >> +
> >> +SRC_URI = 
> >> "${SOURCEFORGE_MIRROR}/project/mingw-w64/mingw-w64/mingw-w64-release/mingw-w64-v${PV}.tar.bz2"
> >> +SRC_URI[md5sum] = "5524c20312560cc8683b7d8ee292cb8c"
> >> 

[yocto] QEMU kernel defconfigs

[Jon Mason]

I'm having difficulty determining where the kernel defconfigs are
defined and located.  I'm specifically looking for the qemuarm and
qemuarm64 kernel defconfigs.  I've looked at the relevant
documentation, 
https://www.yoctoproject.org/docs/2.5.1/kernel-dev/kernel-dev.html#using-an-in-tree-defconfig-file
and
no SRC_URI with defconfig or KBUILD_DEFCONFIG_KMACHINE defined in
meta/recipes-kernel/linux/linux-yocto_4.18.bb

What am I missing?

Also, "A defconfig file is simply a .config renamed to "defconfig"."
is not correct.  A properly created defconfig is created by `make
savedefconfig` and is a minimal file which only has the delta between
the desired config and defaults from the Kconfig files.
https://www.yoctoproject.org/docs/2.5.1/kernel-dev/kernel-dev.html#creating-a-defconfig-file

Thanks,
Jon
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-mingw][PATCH 1/2] winpthreads: use posix threads library from mingw64

[Burton, Ross]

I see 1/2 but no 2/2, presumably this missing patch is the PIE one?

Ross
On Thu, 15 Nov 2018 at 16:04, Samuli Piippo  wrote:
>
> Use the winpthreads library available in the mingw64 and
> change the thread model from win32 to posix to get access
> to c++11 features.
>
> Signed-off-by: Samuli Piippo 
> ---
>  conf/machine-sdk/include/mingw32-common.inc   |  2 -
>  recipes-core/gettext/gettext_0.19.%.bbappend  |  5 +-
>  recipes-devtools/gcc/gcc-runtime_%.bbappend   |  2 +-
>  recipes-devtools/gcc/libgcc_%.bbappend|  2 +
>  .../nativesdk-mingw-w64-headers_5.0.3.bb  |  5 ++
>  .../nativesdk-mingw-w64-winpthreads_5.0.3.bb  | 31 
>  .../pthreads-win32/pthreads-win32_2.9.1.bb| 47 ---
>  7 files changed, 40 insertions(+), 54 deletions(-)
>  create mode 100644 
> recipes-devtools/mingw-w64/nativesdk-mingw-w64-winpthreads_5.0.3.bb
>  delete mode 100644 recipes-devtools/pthreads-win32/pthreads-win32_2.9.1.bb
>
> diff --git a/conf/machine-sdk/include/mingw32-common.inc 
> b/conf/machine-sdk/include/mingw32-common.inc
> index cd56380..733d092 100644
> --- a/conf/machine-sdk/include/mingw32-common.inc
> +++ b/conf/machine-sdk/include/mingw32-common.inc
> @@ -1,8 +1,6 @@
>  SDK_OS = "mingw32"
>  NATIVESDKLIBC = "libc-mingw"
>
> -GCCTHREADS_mingw32 = "win32"
> -
>  PREFERRED_PROVIDER_virtual/nativesdk-${SDK_PREFIX}libc-for-gcc_mingw32 = 
> "nativesdk-mingw-w64-runtime"
>  PREFERRED_PROVIDER_virtual/nativesdk-${SDK_PREFIX}libc-initial_mingw32 = 
> "nativesdk-mingw-w64-runtime"
>  PREFERRED_PROVIDER_virtual/nativesdk-libc = "nativesdk-mingw-w64-runtime"
> diff --git a/recipes-core/gettext/gettext_0.19.%.bbappend 
> b/recipes-core/gettext/gettext_0.19.%.bbappend
> index b26b734..21749f3 100644
> --- a/recipes-core/gettext/gettext_0.19.%.bbappend
> +++ b/recipes-core/gettext/gettext_0.19.%.bbappend
> @@ -1,7 +1,4 @@
> -DEPENDS_append_mingw32 = " pthreads-win32"
> -LDFLAGS_prepend_mingw32 = " -lpthread "
> -
> -EXTRA_OECONF_append_mingw32 = " --enable-threads=windows --enable-static"
> +EXTRA_OECONF_append_mingw32 = " --enable-static"
>
>  FILESEXTRAPATHS_prepend_mingw32 := "${THISDIR}/${BPN}:"
>  SRC_URI_append_mingw32 = " \
> diff --git a/recipes-devtools/gcc/gcc-runtime_%.bbappend 
> b/recipes-devtools/gcc/gcc-runtime_%.bbappend
> index 1641cb9..f14edf1 100644
> --- a/recipes-devtools/gcc/gcc-runtime_%.bbappend
> +++ b/recipes-devtools/gcc/gcc-runtime_%.bbappend
> @@ -11,4 +11,4 @@ RUNTIMETARGET_remove_mingw32 = "libitm"
>  # mingw builds
>  RUNTIMETARGET_remove_mingw32 = "libmpx"
>
> -DEPENDS_append_mingw32 = " pthreads-win32"
> +DEPENDS_append_mingw32 = " nativesdk-mingw-w64-winpthreads"
> diff --git a/recipes-devtools/gcc/libgcc_%.bbappend 
> b/recipes-devtools/gcc/libgcc_%.bbappend
> index 2a95d02..f542cfc 100644
> --- a/recipes-devtools/gcc/libgcc_%.bbappend
> +++ b/recipes-devtools/gcc/libgcc_%.bbappend
> @@ -1,3 +1,5 @@
> +DEPENDS_append_mingw32 = " nativesdk-mingw-w64-winpthreads"
> +
>  FILES_${PN}_append_mingw32 = " ${bindir}/libgcc*.dll"
>  FILES_${PN}-dev_append_mingw32 = " ${base_libdir}/libgcc*.a"
>
> diff --git a/recipes-devtools/mingw-w64/nativesdk-mingw-w64-headers_5.0.3.bb 
> b/recipes-devtools/mingw-w64/nativesdk-mingw-w64-headers_5.0.3.bb
> index e129c32..009e5af 100644
> --- a/recipes-devtools/mingw-w64/nativesdk-mingw-w64-headers_5.0.3.bb
> +++ b/recipes-devtools/mingw-w64/nativesdk-mingw-w64-headers_5.0.3.bb
> @@ -31,4 +31,9 @@ do_compile() {
> :
>  }
>
> +do_install_append() {
> +# install correct pthread headers
> +install -m 0644 -t ${D}${includedir} 
> ${S}/../mingw-w64-libraries/winpthreads/include/*.h
> +}
> +
>  FILES_${PN} += "${exec_prefix}/${TARGET_SYS}"
> diff --git 
> a/recipes-devtools/mingw-w64/nativesdk-mingw-w64-winpthreads_5.0.3.bb 
> b/recipes-devtools/mingw-w64/nativesdk-mingw-w64-winpthreads_5.0.3.bb
> new file mode 100644
> index 000..1308760
> --- /dev/null
> +++ b/recipes-devtools/mingw-w64/nativesdk-mingw-w64-winpthreads_5.0.3.bb
> @@ -0,0 +1,31 @@
> +DESCRIPTION = "Winpthreads runtime libraries from MinGW-w64 project"
> +LICENSE = "ZPL-2.1"
> +LIC_FILES_CHKSUM = 
> "file://../../COPYING;md5=bb936f0e04d8f1e19ad545100cee9654"
> +
> +COMPATIBLE_HOST = ".*-mingw.*"
> +
> +SRC_URI = 
> "${SOURCEFORGE_MIRROR}/project/mingw-w64/mingw-w64/mingw-w64-release/mingw-w64-v${PV}.tar.bz2"
> +SRC_URI[md5sum] = "5524c20312560cc8683b7d8ee292cb8c"
> +SRC_URI[sha256sum] = 
> "2a601db99ef579b9be69c775218ad956a24a09d7dabc9ff6c5bd60da9ccc9cb4"
> +
> +S = "${WORKDIR}/mingw-w64-v${PV}/mingw-w64-libraries/winpthreads"
> +B = "${WORKDIR}/build-${TARGET_SYS}"
> +
> +inherit autotools nativesdk
> +
> +INHIBIT_DEFAULT_DEPS = "1"
> +DEPENDS = "nativesdk-mingw-w64-runtime virtual/${TARGET_PREFIX}gcc-initial"
> +
> +do_configure() {
> +oe_runconf
> +}
> +
> +STAGINGCC = "gcc-cross-initial-${TARGET_ARCH}"
> +STAGINGCC_class-nativesdk = "gcc-crosssdk-initial-${SDK_SYS}"
> +TOOLCHAIN_OPTIONS = " --sysroot=${STAGING_DIR_TARGET}"
> 

[yocto] Canceled event with note: Yocto Project Weekly Triage Meeting @ Thu Nov 22, 2018 7:30am - 8:30am (PST) (yocto@yoctoproject.org)

[theyoctoproject]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:CANCEL
BEGIN:VTIMEZONE
TZID:America/Los_Angeles
X-LIC-LOCATION:America/Los_Angeles
BEGIN:DAYLIGHT
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
TZNAME:PDT
DTSTART:19700308T02
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
TZNAME:PST
DTSTART:19701101T02
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=America/Los_Angeles:20181122T073000
DTEND;TZID=America/Los_Angeles:20181122T083000
DTSTAMP:20181115T163749Z
ORGANIZER;CN=theyoctoproj...@gmail.com:mailto:theyoctoproj...@gmail.com
UID:69b8n4lifp3et8i02e5gp0h...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=yo
 c...@yoctoproject.org;X-NUM-GUESTS=0:mailto:yocto@yoctoproject.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;CN=theyoc
 toproj...@gmail.com;X-NUM-GUESTS=0:mailto:theyoctoproj...@gmail.com
RECURRENCE-ID;TZID=America/Los_Angeles:20181122T073000
CREATED:20180524T175433Z
DESCRIPTION:Yocto Project Weekly Triage Meeting Details\n\n\nWiki: https://
 wiki.yoctoproject.org/wiki/Bug_Triage\n\n\nYocto IRC: http://webchat.freeno
 de.net/?channels=#yocto - When you join state your name on the bridge or IR
 C.\n\nWe use a Zoom Bridge at: https://zoom.us/j/454367603
LAST-MODIFIED:20181115T163749Z
LOCATION:Zoom Meeting: https://zoom.us/j/454367603
SEQUENCE:1
STATUS:CANCELLED
SUMMARY:Yocto Project Weekly Triage Meeting
TRANSP:OPAQUE
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:This is an event reminder
TRIGGER:-P0DT0H15M0S
END:VALARM
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] FW: final pass on release notes....and general status of readiness

[akuster808]

Stephen,

Please add "multiconfig in no longer works with COMPATIBLE_MACHINE" bug
12985

thanks,

Armin

On 11/14/18 2:02 PM, Scott Rifenbark wrote:
> Especially true for the manuals... always go to the website for best
> set of manuals.
>
> Scott
>
> On Wed, Nov 14, 2018 at 1:41 PM akuster808  > wrote:
>
>
> On 11/14/18 12:47 PM, Jolley, Stephen K wrote:
>>
>> We will release YP 2.6 M4 rc1 shortly.  Please give feedback if
>> any is required.
>>
>
> Please add the note that Tip of Thud is not what is being released.
>
> This will just confuse folks trying to connect the dots.
>
>
> - armin
>
>>  
>>
>> Thanks,
>>
>>  
>>
>> Stephen
>>
>>  
>>
>> *From:* Graydon, Tracy
>> *Sent:* Wednesday, November 14, 2018 12:33 PM
>> *To:* Jolley, Stephen K 
>> ; Michael Halstead
>> 
>> 
>> *Subject:* final pass on release notesand general status of
>> readiness
>>
>>  
>>
>> Ugh, I am not seeing the email I sent with the finalized release
>> notes. I dunno if I sent it or not because I am having a
>> nightmare with Outlook on Mac eating things and generally not
>> working right.
>>
>>
>> So, by way of sanity check, attached.  The only changes were
>> adding the binutils CVES to Known issues:
>>
>>  
>>
>> binutils: fix CVE-2018-18309, CVE-2018-18605, CVE-2018-18606,
>> CVE-2018-18607
>>
>>  
>>
>> And the gitsm known issue:
>>
>>  
>>
>> - gitsm fixes on master-next:
>>
>> * The submodule name and path were assumed to be the same, which
>> is not necessarily true.
>>
>> * Submodules refer to a specific commit, not branch, but we
>> erroneously check against the branch specified in SRC_URI. This
>> results in
>>
>> failure if a submodule commit is not on that branch.
>>
>>  
>>
>> So, nothing major there. Just really a sanity check on the gitsm
>> wording.
>>
>>  
>>
>> Everything is ready to go. Pages are set and just need to be
>> published. Release announcement is ready. So we just need to do
>> the final mirror and tagging magic, and announce.
>>
>>  
>>
>> If the wording on gitsm issue looks reasonable, we are good to go.
>>
>>  
>>
>> -t
>>
>>  
>>
>>  
>>
> -- 
> ___
> yocto mailing list
> yocto@yoctoproject.org 
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Invitation: Yocto Project Weekly Triage Meeting @ Weekly from 7:30am to 8:30am on Thursday (PDT) (yocto@yoctoproject.org)

[Jolley, Stephen K]

This is Thanksgiving.   I will be canceled.

Thanks,

Stephen


-Original Appointment-
From: theyoctoproj...@gmail.com [mailto:theyoctoproj...@gmail.com]
Sent: Thursday, May 24, 2018 2:17 PM
To: theyoctoproj...@gmail.com; yocto@yoctoproject.org
Subject: [yocto] Invitation: Yocto Project Weekly Triage Meeting @ Weekly from 
7:30am to 8:30am on Thursday (PDT) (yocto@yoctoproject.org)
When: Thursday, November 22, 2018 7:30 AM-8:30 AM America/Los_Angeles.
Where: Zoom Meeting: https://zoom.us/j/454367603


more details 
»

Yocto Project Weekly Triage Meeting
When
Weekly from 7:30am to 8:30am on Thursday Pacific Time

Where
Zoom Meeting: https://zoom.us/j/454367603 
(map)

Calendar
yocto@yoctoproject.org

Who
•
theyoctoproj...@gmail.com - organizer

•
yocto@yoctoproject.org



Yocto Project Weekly Triage Meeting Details

Wiki: 
https://wiki.yoctoproject.org/wiki/Bug_Triage

Yocto IRC: 
http://webchat.freenode.net/?channels=#yocto
 - When you join state your name on the bridge or IRC.
We use a Zoom Bridge at: 
https://zoom.us/j/454367603


Going?   All events in this series:   
Yes
 - 
Maybe
 - 
No
more options 
»
Invitation from Google Calendar

You are receiving this courtesy email at the account yocto@yoctoproject.org 
because you are an attendee of this event.
To stop receiving future updates for this event, decline this event. 
Alternatively you can sign up for a Google account at 
https://www.google.com/calendar/ and control your notification settings for 
your entire calendar.
Forwarding this invitation could allow any recipient to modify your RSVP 
response. Learn 
More.
 << File: invite.ics >>  << File: ATT1.txt >>

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-mingw][PATCH 1/2] winpthreads: use posix threads library from mingw64

[Samuli Piippo]

Use the winpthreads library available in the mingw64 and
change the thread model from win32 to posix to get access
to c++11 features.

Signed-off-by: Samuli Piippo 
---
 conf/machine-sdk/include/mingw32-common.inc   |  2 -
 recipes-core/gettext/gettext_0.19.%.bbappend  |  5 +-
 recipes-devtools/gcc/gcc-runtime_%.bbappend   |  2 +-
 recipes-devtools/gcc/libgcc_%.bbappend|  2 +
 .../nativesdk-mingw-w64-headers_5.0.3.bb  |  5 ++
 .../nativesdk-mingw-w64-winpthreads_5.0.3.bb  | 31 
 .../pthreads-win32/pthreads-win32_2.9.1.bb| 47 ---
 7 files changed, 40 insertions(+), 54 deletions(-)
 create mode 100644 
recipes-devtools/mingw-w64/nativesdk-mingw-w64-winpthreads_5.0.3.bb
 delete mode 100644 recipes-devtools/pthreads-win32/pthreads-win32_2.9.1.bb

diff --git a/conf/machine-sdk/include/mingw32-common.inc 
b/conf/machine-sdk/include/mingw32-common.inc
index cd56380..733d092 100644
--- a/conf/machine-sdk/include/mingw32-common.inc
+++ b/conf/machine-sdk/include/mingw32-common.inc
@@ -1,8 +1,6 @@
 SDK_OS = "mingw32"
 NATIVESDKLIBC = "libc-mingw"
 
-GCCTHREADS_mingw32 = "win32"
-
 PREFERRED_PROVIDER_virtual/nativesdk-${SDK_PREFIX}libc-for-gcc_mingw32 = 
"nativesdk-mingw-w64-runtime"
 PREFERRED_PROVIDER_virtual/nativesdk-${SDK_PREFIX}libc-initial_mingw32 = 
"nativesdk-mingw-w64-runtime"
 PREFERRED_PROVIDER_virtual/nativesdk-libc = "nativesdk-mingw-w64-runtime"
diff --git a/recipes-core/gettext/gettext_0.19.%.bbappend 
b/recipes-core/gettext/gettext_0.19.%.bbappend
index b26b734..21749f3 100644
--- a/recipes-core/gettext/gettext_0.19.%.bbappend
+++ b/recipes-core/gettext/gettext_0.19.%.bbappend
@@ -1,7 +1,4 @@
-DEPENDS_append_mingw32 = " pthreads-win32"
-LDFLAGS_prepend_mingw32 = " -lpthread "
-
-EXTRA_OECONF_append_mingw32 = " --enable-threads=windows --enable-static"
+EXTRA_OECONF_append_mingw32 = " --enable-static"
 
 FILESEXTRAPATHS_prepend_mingw32 := "${THISDIR}/${BPN}:"
 SRC_URI_append_mingw32 = " \
diff --git a/recipes-devtools/gcc/gcc-runtime_%.bbappend 
b/recipes-devtools/gcc/gcc-runtime_%.bbappend
index 1641cb9..f14edf1 100644
--- a/recipes-devtools/gcc/gcc-runtime_%.bbappend
+++ b/recipes-devtools/gcc/gcc-runtime_%.bbappend
@@ -11,4 +11,4 @@ RUNTIMETARGET_remove_mingw32 = "libitm"
 # mingw builds
 RUNTIMETARGET_remove_mingw32 = "libmpx"
 
-DEPENDS_append_mingw32 = " pthreads-win32"
+DEPENDS_append_mingw32 = " nativesdk-mingw-w64-winpthreads"
diff --git a/recipes-devtools/gcc/libgcc_%.bbappend 
b/recipes-devtools/gcc/libgcc_%.bbappend
index 2a95d02..f542cfc 100644
--- a/recipes-devtools/gcc/libgcc_%.bbappend
+++ b/recipes-devtools/gcc/libgcc_%.bbappend
@@ -1,3 +1,5 @@
+DEPENDS_append_mingw32 = " nativesdk-mingw-w64-winpthreads"
+
 FILES_${PN}_append_mingw32 = " ${bindir}/libgcc*.dll"
 FILES_${PN}-dev_append_mingw32 = " ${base_libdir}/libgcc*.a"
 
diff --git a/recipes-devtools/mingw-w64/nativesdk-mingw-w64-headers_5.0.3.bb 
b/recipes-devtools/mingw-w64/nativesdk-mingw-w64-headers_5.0.3.bb
index e129c32..009e5af 100644
--- a/recipes-devtools/mingw-w64/nativesdk-mingw-w64-headers_5.0.3.bb
+++ b/recipes-devtools/mingw-w64/nativesdk-mingw-w64-headers_5.0.3.bb
@@ -31,4 +31,9 @@ do_compile() {
:
 }
 
+do_install_append() {
+# install correct pthread headers
+install -m 0644 -t ${D}${includedir} 
${S}/../mingw-w64-libraries/winpthreads/include/*.h
+}
+
 FILES_${PN} += "${exec_prefix}/${TARGET_SYS}"
diff --git 
a/recipes-devtools/mingw-w64/nativesdk-mingw-w64-winpthreads_5.0.3.bb 
b/recipes-devtools/mingw-w64/nativesdk-mingw-w64-winpthreads_5.0.3.bb
new file mode 100644
index 000..1308760
--- /dev/null
+++ b/recipes-devtools/mingw-w64/nativesdk-mingw-w64-winpthreads_5.0.3.bb
@@ -0,0 +1,31 @@
+DESCRIPTION = "Winpthreads runtime libraries from MinGW-w64 project"
+LICENSE = "ZPL-2.1"
+LIC_FILES_CHKSUM = "file://../../COPYING;md5=bb936f0e04d8f1e19ad545100cee9654"
+
+COMPATIBLE_HOST = ".*-mingw.*"
+
+SRC_URI = 
"${SOURCEFORGE_MIRROR}/project/mingw-w64/mingw-w64/mingw-w64-release/mingw-w64-v${PV}.tar.bz2"
+SRC_URI[md5sum] = "5524c20312560cc8683b7d8ee292cb8c"
+SRC_URI[sha256sum] = 
"2a601db99ef579b9be69c775218ad956a24a09d7dabc9ff6c5bd60da9ccc9cb4"
+
+S = "${WORKDIR}/mingw-w64-v${PV}/mingw-w64-libraries/winpthreads"
+B = "${WORKDIR}/build-${TARGET_SYS}"
+
+inherit autotools nativesdk
+
+INHIBIT_DEFAULT_DEPS = "1"
+DEPENDS = "nativesdk-mingw-w64-runtime virtual/${TARGET_PREFIX}gcc-initial"
+
+do_configure() {
+oe_runconf
+}
+
+STAGINGCC = "gcc-cross-initial-${TARGET_ARCH}"
+STAGINGCC_class-nativesdk = "gcc-crosssdk-initial-${SDK_SYS}"
+TOOLCHAIN_OPTIONS = " --sysroot=${STAGING_DIR_TARGET}"
+PATH_prepend = "${STAGING_BINDIR_TOOLCHAIN}.${STAGINGCC}:"
+
+do_install_append() {
+# headers are already installed by mingw-w64-headers
+rm -rf ${D}${includedir}
+}
diff --git a/recipes-devtools/pthreads-win32/pthreads-win32_2.9.1.bb 
b/recipes-devtools/pthreads-win32/pthreads-win32_2.9.1.bb
deleted file mode 100644
index e4a0f80..000
--- 

[yocto] [meta-security][PATCH][sumo] Use git fetcher for lynis to fetch older versions

[Stefan Lendl]

From: Stefan Lendl 

---
 meta-security-compliance/recipes-auditors/lynis/lynis_2.5.1.bb | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/meta-security-compliance/recipes-auditors/lynis/lynis_2.5.1.bb 
b/meta-security-compliance/recipes-auditors/lynis/lynis_2.5.1.bb
index c25b804..38149a3 100644
--- a/meta-security-compliance/recipes-auditors/lynis/lynis_2.5.1.bb
+++ b/meta-security-compliance/recipes-auditors/lynis/lynis_2.5.1.bb
@@ -6,12 +6,8 @@ HOMEDIR = "https://cisofy.com/;
 LICENSE = "GPL-3.0"
 LIC_FILES_CHKSUM = "file://LICENSE;md5=3edd6782854304fd11da4975ab9799c1"
 
-SRC_URI = "https://cisofy.com/files/${BPN}-${PV}.tar.gz;
-
-SRC_URI[md5sum] = "5b9da89c616344bbc73cbc5688a4a0bd"
-SRC_URI[sha256sum] = 
"7a09c6fc71c65d572ca702df7b4394d71f9037484062ef71b76f59a2c498b029"
-
-S = "${WORKDIR}/${BPN}"
+SRC_URI = "git://github.com/CISOfy/Lynis.git;protocol=https;tag=${PV}"
+S = "${WORKDIR}/git"
 
 inherit autotools-brokensep
 
-- 
2.14.5

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-security][PATCH][sumo] Use git fetcher for lynis to fetch older versions

[Stefan Lendl]

---
 meta-security-compliance/recipes-auditors/lynis/lynis_2.5.1.bb | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/meta-security-compliance/recipes-auditors/lynis/lynis_2.5.1.bb 
b/meta-security-compliance/recipes-auditors/lynis/lynis_2.5.1.bb
index c25b804..38149a3 100644
--- a/meta-security-compliance/recipes-auditors/lynis/lynis_2.5.1.bb
+++ b/meta-security-compliance/recipes-auditors/lynis/lynis_2.5.1.bb
@@ -6,12 +6,8 @@ HOMEDIR = "https://cisofy.com/;
 LICENSE = "GPL-3.0"
 LIC_FILES_CHKSUM = "file://LICENSE;md5=3edd6782854304fd11da4975ab9799c1"
 
-SRC_URI = "https://cisofy.com/files/${BPN}-${PV}.tar.gz;
-
-SRC_URI[md5sum] = "5b9da89c616344bbc73cbc5688a4a0bd"
-SRC_URI[sha256sum] = 
"7a09c6fc71c65d572ca702df7b4394d71f9037484062ef71b76f59a2c498b029"
-
-S = "${WORKDIR}/${BPN}"
+SRC_URI = "git://github.com/CISOfy/Lynis.git;protocol=https;tag=${PV}"
+S = "${WORKDIR}/git"
 
 inherit autotools-brokensep
 
-- 
2.14.5

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] meta-mingw: unable to run executables on Windows

[Mark Hatle]

On 11/14/18 11:01 PM, Khem Raj wrote:
> On Wed, Nov 14, 2018 at 8:08 PM Joshua Watt  wrote:
>>
>> On Wed, Nov 14, 2018 at 8:41 PM Mark Hatle  wrote:
>>>
>>> On 11/14/18 9:54 AM, Mark Hatle wrote:
 On 11/13/18 3:56 AM, Samuli Piippo wrote:
> Hi,
>
> I've just upgraded poky and meta-mingw layers from sumo to thud and as a 
> result
> a lot of the executables in the toolchain no longer run correctly on 
> Windows.

 Which version of windows?

> I've built meta-toolchain for SDKMACHINE=x86_64-mingw32. From that, 
> gcc/g++ work
> fine on Windows 10, but ar, as, objdumb, and others hang for ~30 seconds 
> and
> exit without any output.
>
> Has anyone else seen this?

 I've run a toolchain made on mingw after sumo, but before thud's release.  
 I'll
 see if I can find a VM and give it a try later today.
>>>
>>> I'm running on Windows 7 for my testing (ya, I know old.. but it's what I 
>>> got.)
>>>
>>> Can you try adding the following to your conf/local.conf: GCCPIE_mingw32 = 
>>> ""
> 
> this will be effective just for SDK and native versions I hope, but in
> cases if we
> have this override also applicable for target then this fix is not
> correct. We have
> to keep using it for target builds.

The mingw32 override is only present when building -nativesdk- mingw32 software.
 -Not- cross candian and similar.

--Mark

>>>
>>> I found that the SDK was not working properly here as well, but only 
>>> binutils.
>>> The above seems to fix the issue.  (You do have to rebuild your SDK.)
>>
>> I also saw this issue on Windows 7, and your described fix corrected
>> it (Thanks!). On the plus side, the automated SDK testing that I'm
>> working on discovered it as well (e.g. the tests failed because of
>> it), which means that the tests are working and should help prevent
>> issues like this in the future once I get it merged.
>>
>>>
 --Mark

>>>
>>> --
>>> ___
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] meta-mingw: unable to run executables on Windows

[Burton, Ross]

Didn't see it arrive, maybe it's lost in moderation?  What list did
you post it to?

Ross
On Thu, 15 Nov 2018 at 09:28, Samuli Piippo  wrote:
>
> patch sent.
> On Thu, 15 Nov 2018 at 11:17, Burton, Ross  wrote:
> >
> > Good work!
> >
> > Can we have a patch from someone please?
> >
> > Ross
> >
> > On Thu, 15 Nov 2018 at 08:35, Samuli Piippo  wrote:
> >>
> >> On Thu, 15 Nov 2018 at 07:01, Khem Raj  wrote:
> >> >
> >> > On Wed, Nov 14, 2018 at 8:08 PM Joshua Watt  wrote:
> >> > >
> >> > > On Wed, Nov 14, 2018 at 8:41 PM Mark Hatle  
> >> > > wrote:
> >> > > >
> >> > > > On 11/14/18 9:54 AM, Mark Hatle wrote:
> >> > > > > On 11/13/18 3:56 AM, Samuli Piippo wrote:
> >> > > > >> Hi,
> >> > > > >>
> >> > > > >> I've just upgraded poky and meta-mingw layers from sumo to thud 
> >> > > > >> and as a result
> >> > > > >> a lot of the executables in the toolchain no longer run correctly 
> >> > > > >> on Windows.
> >> > > > >
> >> > > > > Which version of windows?
> >> > > > >
> >> > > > >> I've built meta-toolchain for SDKMACHINE=x86_64-mingw32. From 
> >> > > > >> that, gcc/g++ work
> >> > > > >> fine on Windows 10, but ar, as, objdumb, and others hang for ~30 
> >> > > > >> seconds and
> >> > > > >> exit without any output.
> >> > > > >>
> >> > > > >> Has anyone else seen this?
> >> > > > >
> >> > > > > I've run a toolchain made on mingw after sumo, but before thud's 
> >> > > > > release.  I'll
> >> > > > > see if I can find a VM and give it a try later today.
> >> > > >
> >> > > > I'm running on Windows 7 for my testing (ya, I know old.. but it's 
> >> > > > what I got.)
> >> > > >
> >> > > > Can you try adding the following to your conf/local.conf: 
> >> > > > GCCPIE_mingw32 = ""
> >> >
> >> > this will be effective just for SDK and native versions I hope, but in
> >> > cases if we
> >> > have this override also applicable for target then this fix is not
> >> > correct. We have
> >> > to keep using it for target builds.
> >> >
> >> > > >
> >> > > > I found that the SDK was not working properly here as well, but only 
> >> > > > binutils.
> >> > > > The above seems to fix the issue.  (You do have to rebuild your SDK.)
> >> > >
> >> > > I also saw this issue on Windows 7, and your described fix corrected
> >> > > it (Thanks!). On the plus side, the automated SDK testing that I'm
> >> > > working on discovered it as well (e.g. the tests failed because of
> >> > > it), which means that the tests are working and should help prevent
> >> > > issues like this in the future once I get it merged.
> >> > >
> >>
> >> bisect finished last night and the winner was: commit
> >> 491082c56ce34f3fd644f8d4457ccd52af951087
> >> poky.conf: Enable security flags+pie by defaultEnable security
> >> flags+pie by default
> >>
> >> Adding GCCPIE_mingw32 = "" fixes this also for Windows 10
> >> --
> >> ___
> >> yocto mailing list
> >> yocto@yoctoproject.org
> >> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH] Use lynis download link from github releases

[Joshua Watt]

On Thu, Nov 15, 2018, 8:29 AM Stefan Lendl  Unlike the official download page, it also works for older releases
>
> Signed-off-by: Stefan Lendl 
> ---
>  meta-security-compliance/recipes-auditors/lynis/lynis_2.5.1.bb | 8
> 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/meta-security-compliance/recipes-auditors/lynis/
> lynis_2.5.1.bb b/meta-security-compliance/recipes-auditors/lynis/
> lynis_2.5.1.bb
> index c25b804..1ee71ef 100644
> --- a/meta-security-compliance/recipes-auditors/lynis/lynis_2.5.1.bb
> +++ b/meta-security-compliance/recipes-auditors/lynis/lynis_2.5.1.bb
> @@ -6,12 +6,12 @@ HOMEDIR = "https://cisofy.com/;
>  LICENSE = "GPL-3.0"
>  LIC_FILES_CHKSUM = "file://LICENSE;md5=3edd6782854304fd11da4975ab9799c1"
>
> -SRC_URI = "https://cisofy.com/files/${BPN}-${PV}.tar.gz;
> +SRC_URI = "https://github.com/CISOfy/lynis/archive/${PV}.tar.gz;
>

Using the archive links from GitHub in the past has caused problems because
the checksums change. I think most other recipes use the git fetcher and
specify the sha1 that corresponds to the release.


> -SRC_URI[md5sum] = "5b9da89c616344bbc73cbc5688a4a0bd"
> -SRC_URI[sha256sum] =
> "7a09c6fc71c65d572ca702df7b4394d71f9037484062ef71b76f59a2c498b029"
> +SRC_URI[md5sum] = "f91840acc0801b77844363fc55c5d688"
> +SRC_URI[sha256sum] =
> "e143eaefec3222f98a0f74dd6dcb3818aa348dea3d0379bd3a45455911b6ee2a"
>
> -S = "${WORKDIR}/${BPN}"
> +S = "${WORKDIR}/${BPN}-${PV}"
>
>  inherit autotools-brokensep
>
> --
> 2.14.5
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH] Use lynis download link from github releases

[Stefan Lendl]

Unlike the official download page, it also works for older releases

Signed-off-by: Stefan Lendl 
---
 meta-security-compliance/recipes-auditors/lynis/lynis_2.5.1.bb | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta-security-compliance/recipes-auditors/lynis/lynis_2.5.1.bb 
b/meta-security-compliance/recipes-auditors/lynis/lynis_2.5.1.bb
index c25b804..1ee71ef 100644
--- a/meta-security-compliance/recipes-auditors/lynis/lynis_2.5.1.bb
+++ b/meta-security-compliance/recipes-auditors/lynis/lynis_2.5.1.bb
@@ -6,12 +6,12 @@ HOMEDIR = "https://cisofy.com/;
 LICENSE = "GPL-3.0"
 LIC_FILES_CHKSUM = "file://LICENSE;md5=3edd6782854304fd11da4975ab9799c1"
 
-SRC_URI = "https://cisofy.com/files/${BPN}-${PV}.tar.gz;
+SRC_URI = "https://github.com/CISOfy/lynis/archive/${PV}.tar.gz;
 
-SRC_URI[md5sum] = "5b9da89c616344bbc73cbc5688a4a0bd"
-SRC_URI[sha256sum] = 
"7a09c6fc71c65d572ca702df7b4394d71f9037484062ef71b76f59a2c498b029"
+SRC_URI[md5sum] = "f91840acc0801b77844363fc55c5d688"
+SRC_URI[sha256sum] = 
"e143eaefec3222f98a0f74dd6dcb3818aa348dea3d0379bd3a45455911b6ee2a"
 
-S = "${WORKDIR}/${BPN}"
+S = "${WORKDIR}/${BPN}-${PV}"
 
 inherit autotools-brokensep
 
-- 
2.14.5

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH] Use lynis download link from github releases

[Burton, Ross]

On Thu, 15 Nov 2018 at 14:29, Stefan Lendl  wrote:
> -SRC_URI = "https://cisofy.com/files/${BPN}-${PV}.tar.gz;
> +SRC_URI = "https://github.com/CISOfy/lynis/archive/${PV}.tar.gz;

NAK.

Those tarballs are generated on demand by github so over time *will*
change.  If they don't host generated tarballs (similar URL but the
filename isn't the tag name) then the only alternative is to use the
git fetcher.

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH] Use lynis download link from github releases

[Stefan Lendl]

Unlike the official download page, it also works for older releases

Signed-off-by: Stefan Lendl 
---
 meta-security-compliance/recipes-auditors/lynis/lynis_2.5.1.bb | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta-security-compliance/recipes-auditors/lynis/lynis_2.5.1.bb 
b/meta-security-compliance/recipes-auditors/lynis/lynis_2.5.1.bb
index c25b804..1ee71ef 100644
--- a/meta-security-compliance/recipes-auditors/lynis/lynis_2.5.1.bb
+++ b/meta-security-compliance/recipes-auditors/lynis/lynis_2.5.1.bb
@@ -6,12 +6,12 @@ HOMEDIR = "https://cisofy.com/;
 LICENSE = "GPL-3.0"
 LIC_FILES_CHKSUM = "file://LICENSE;md5=3edd6782854304fd11da4975ab9799c1"
 
-SRC_URI = "https://cisofy.com/files/${BPN}-${PV}.tar.gz;
+SRC_URI = "https://github.com/CISOfy/lynis/archive/${PV}.tar.gz;
 
-SRC_URI[md5sum] = "5b9da89c616344bbc73cbc5688a4a0bd"
-SRC_URI[sha256sum] = 
"7a09c6fc71c65d572ca702df7b4394d71f9037484062ef71b76f59a2c498b029"
+SRC_URI[md5sum] = "f91840acc0801b77844363fc55c5d688"
+SRC_URI[sha256sum] = 
"e143eaefec3222f98a0f74dd6dcb3818aa348dea3d0379bd3a45455911b6ee2a"
 
-S = "${WORKDIR}/${BPN}"
+S = "${WORKDIR}/${BPN}-${PV}"
 
 inherit autotools-brokensep
 
-- 
2.14.5

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH] ref-manual: add EXCLUDE_PACKAGES_FROM_SHLIBS description

[Oleksii Konoplitskyi]

Some packages containing shared libraries might be registered as shlib
providers when they shouldn't (for example, the lib is for their private use
and must not generate any dependency).

EXCLUDE_FROM_SHLIBS is targeted at that, but it could be set for entire 
recipe

only.

Variable EXCLUDE_PACKAGES_FROM_SHLIBS allows to set list of packages 
that are

not candidates for shlib providers.

Signed-off-by: Oleksii Konoplitskyi 
---
 documentation/ref-manual/ref-variables.xml | 28 


 1 file changed, 28 insertions(+)

diff --git a/documentation/ref-manual/ref-variables.xml 
b/documentation/ref-manual/ref-variables.xml

index 595f2db..98d3f86 100644
--- a/documentation/ref-manual/ref-variables.xml
+++ b/documentation/ref-manual/ref-variables.xml
@@ -4289,6 +4289,34 @@
 
 

+    id='var-EXCLUDE_PACKAGES_FROM_SHLIBS'>EXCLUDE_PACKAGES_FROM_SHLIBS

+    
+    EXCLUDE_PACKAGES_FROM_SHLIBS[doc] = "Causes the 
OpenEmbedded build system's shared libraries resolver to exclude 
packages when scanning for shared libraries."

+    
+    
+    
+
+    Triggers the OpenEmbedded build system's shared 
libraries

+    resolver to exclude packages when scanning for
+    shared libraries.
+    The 
EXCLUDE_PACKAGES_FROM_SHLIBS variable is

+    similar to the
+    linkend='var-EXCLUDE_FROM_SHLIBS'>EXCLUDE_FROM_SHLIBS
+    variable, which excludes all the packages provided 
by recipe

+    and not excludes particular package.
+    
+
+    
+    Use the
+ EXCLUDE_PACKAGES_FROM_SHLIBS variable as a list 
of packages that

+    are not candidates for shared libraries providers:
+    
+ EXCLUDE_PACKAGES_FROM_SHLIBS += "glibc-ptest glibc-dev"
+    
+    
+    
+    
+
 id='var-EXCLUDE_FROM_WORLD'>EXCLUDE_FROM_WORLD

 
 EXCLUDE_FROM_WORLD[doc] = "Directs BitBake to exclude 
a recipe from world builds (i.e. bitbake world)."

--
2.7.4

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] How to let a kernel module depend on another kernel module ?

[winfried . dobbe]

Hi all,

I am upgrading our BSP from Krogoth to Sumo. I have read the 
documentation about the recipe-specific sysroots and this works fine for 
normal recipes.

However I am stuck with upgrading the out-of-tree kernel module recipes.

We have kernel-module-foo and kernel-module-bar. The bar module needs 
header files that foo module installs in usr/include/linux.
I added DEPENDS = "kernel-module-foo" to the recipe of module bar. The 
recipe-sysroot directory for kernel-module-bar does indeed have the foo 
include files.


However compilation of kernel-module-bar stops with an error because it 
can't find the foo header files.


So does anyone know what is the correct way to let one out-of-tree 
kernel module depend on another one?


thanks in advance,

Winfried
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] meta-mingw: unable to run executables on Windows

[Samuli Piippo]

patch sent.
On Thu, 15 Nov 2018 at 11:17, Burton, Ross  wrote:
>
> Good work!
>
> Can we have a patch from someone please?
>
> Ross
>
> On Thu, 15 Nov 2018 at 08:35, Samuli Piippo  wrote:
>>
>> On Thu, 15 Nov 2018 at 07:01, Khem Raj  wrote:
>> >
>> > On Wed, Nov 14, 2018 at 8:08 PM Joshua Watt  wrote:
>> > >
>> > > On Wed, Nov 14, 2018 at 8:41 PM Mark Hatle  
>> > > wrote:
>> > > >
>> > > > On 11/14/18 9:54 AM, Mark Hatle wrote:
>> > > > > On 11/13/18 3:56 AM, Samuli Piippo wrote:
>> > > > >> Hi,
>> > > > >>
>> > > > >> I've just upgraded poky and meta-mingw layers from sumo to thud and 
>> > > > >> as a result
>> > > > >> a lot of the executables in the toolchain no longer run correctly 
>> > > > >> on Windows.
>> > > > >
>> > > > > Which version of windows?
>> > > > >
>> > > > >> I've built meta-toolchain for SDKMACHINE=x86_64-mingw32. From that, 
>> > > > >> gcc/g++ work
>> > > > >> fine on Windows 10, but ar, as, objdumb, and others hang for ~30 
>> > > > >> seconds and
>> > > > >> exit without any output.
>> > > > >>
>> > > > >> Has anyone else seen this?
>> > > > >
>> > > > > I've run a toolchain made on mingw after sumo, but before thud's 
>> > > > > release.  I'll
>> > > > > see if I can find a VM and give it a try later today.
>> > > >
>> > > > I'm running on Windows 7 for my testing (ya, I know old.. but it's 
>> > > > what I got.)
>> > > >
>> > > > Can you try adding the following to your conf/local.conf: 
>> > > > GCCPIE_mingw32 = ""
>> >
>> > this will be effective just for SDK and native versions I hope, but in
>> > cases if we
>> > have this override also applicable for target then this fix is not
>> > correct. We have
>> > to keep using it for target builds.
>> >
>> > > >
>> > > > I found that the SDK was not working properly here as well, but only 
>> > > > binutils.
>> > > > The above seems to fix the issue.  (You do have to rebuild your SDK.)
>> > >
>> > > I also saw this issue on Windows 7, and your described fix corrected
>> > > it (Thanks!). On the plus side, the automated SDK testing that I'm
>> > > working on discovered it as well (e.g. the tests failed because of
>> > > it), which means that the tests are working and should help prevent
>> > > issues like this in the future once I get it merged.
>> > >
>>
>> bisect finished last night and the winner was: commit
>> 491082c56ce34f3fd644f8d4457ccd52af951087
>> poky.conf: Enable security flags+pie by defaultEnable security
>> flags+pie by default
>>
>> Adding GCCPIE_mingw32 = "" fixes this also for Windows 10
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] meta-mingw: unable to run executables on Windows

[Burton, Ross]

Good work!

Can we have a patch from someone please?

Ross

On Thu, 15 Nov 2018 at 08:35, Samuli Piippo  wrote:

> On Thu, 15 Nov 2018 at 07:01, Khem Raj  wrote:
> >
> > On Wed, Nov 14, 2018 at 8:08 PM Joshua Watt 
> wrote:
> > >
> > > On Wed, Nov 14, 2018 at 8:41 PM Mark Hatle 
> wrote:
> > > >
> > > > On 11/14/18 9:54 AM, Mark Hatle wrote:
> > > > > On 11/13/18 3:56 AM, Samuli Piippo wrote:
> > > > >> Hi,
> > > > >>
> > > > >> I've just upgraded poky and meta-mingw layers from sumo to thud
> and as a result
> > > > >> a lot of the executables in the toolchain no longer run correctly
> on Windows.
> > > > >
> > > > > Which version of windows?
> > > > >
> > > > >> I've built meta-toolchain for SDKMACHINE=x86_64-mingw32. From
> that, gcc/g++ work
> > > > >> fine on Windows 10, but ar, as, objdumb, and others hang for ~30
> seconds and
> > > > >> exit without any output.
> > > > >>
> > > > >> Has anyone else seen this?
> > > > >
> > > > > I've run a toolchain made on mingw after sumo, but before thud's
> release.  I'll
> > > > > see if I can find a VM and give it a try later today.
> > > >
> > > > I'm running on Windows 7 for my testing (ya, I know old.. but it's
> what I got.)
> > > >
> > > > Can you try adding the following to your conf/local.conf:
> GCCPIE_mingw32 = ""
> >
> > this will be effective just for SDK and native versions I hope, but in
> > cases if we
> > have this override also applicable for target then this fix is not
> > correct. We have
> > to keep using it for target builds.
> >
> > > >
> > > > I found that the SDK was not working properly here as well, but only
> binutils.
> > > > The above seems to fix the issue.  (You do have to rebuild your SDK.)
> > >
> > > I also saw this issue on Windows 7, and your described fix corrected
> > > it (Thanks!). On the plus side, the automated SDK testing that I'm
> > > working on discovered it as well (e.g. the tests failed because of
> > > it), which means that the tests are working and should help prevent
> > > issues like this in the future once I get it merged.
> > >
>
> bisect finished last night and the winner was: commit
> 491082c56ce34f3fd644f8d4457ccd52af951087
> poky.conf: Enable security flags+pie by defaultEnable security
> flags+pie by default
>
> Adding GCCPIE_mingw32 = "" fixes this also for Windows 10
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] meta-mingw: unable to run executables on Windows

[Samuli Piippo]

On Thu, 15 Nov 2018 at 07:01, Khem Raj  wrote:
>
> On Wed, Nov 14, 2018 at 8:08 PM Joshua Watt  wrote:
> >
> > On Wed, Nov 14, 2018 at 8:41 PM Mark Hatle  wrote:
> > >
> > > On 11/14/18 9:54 AM, Mark Hatle wrote:
> > > > On 11/13/18 3:56 AM, Samuli Piippo wrote:
> > > >> Hi,
> > > >>
> > > >> I've just upgraded poky and meta-mingw layers from sumo to thud and as 
> > > >> a result
> > > >> a lot of the executables in the toolchain no longer run correctly on 
> > > >> Windows.
> > > >
> > > > Which version of windows?
> > > >
> > > >> I've built meta-toolchain for SDKMACHINE=x86_64-mingw32. From that, 
> > > >> gcc/g++ work
> > > >> fine on Windows 10, but ar, as, objdumb, and others hang for ~30 
> > > >> seconds and
> > > >> exit without any output.
> > > >>
> > > >> Has anyone else seen this?
> > > >
> > > > I've run a toolchain made on mingw after sumo, but before thud's 
> > > > release.  I'll
> > > > see if I can find a VM and give it a try later today.
> > >
> > > I'm running on Windows 7 for my testing (ya, I know old.. but it's what I 
> > > got.)
> > >
> > > Can you try adding the following to your conf/local.conf: GCCPIE_mingw32 
> > > = ""
>
> this will be effective just for SDK and native versions I hope, but in
> cases if we
> have this override also applicable for target then this fix is not
> correct. We have
> to keep using it for target builds.
>
> > >
> > > I found that the SDK was not working properly here as well, but only 
> > > binutils.
> > > The above seems to fix the issue.  (You do have to rebuild your SDK.)
> >
> > I also saw this issue on Windows 7, and your described fix corrected
> > it (Thanks!). On the plus side, the automated SDK testing that I'm
> > working on discovered it as well (e.g. the tests failed because of
> > it), which means that the tests are working and should help prevent
> > issues like this in the future once I get it merged.
> >

bisect finished last night and the winner was: commit
491082c56ce34f3fd644f8d4457ccd52af951087
poky.conf: Enable security flags+pie by defaultEnable security
flags+pie by default

Adding GCCPIE_mingw32 = "" fixes this also for Windows 10
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH][meta-yocto] local.conf.sample: update upstream sstate mirror url

[Martin Hundebøll]

The prefilled upstream SSTATE_MIRROR setting in the sample configuration
should match the current Yocto release.

Signed-off-by: Martin Hundebøll 
---
 meta-poky/conf/local.conf.sample | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-poky/conf/local.conf.sample b/meta-poky/conf/local.conf.sample
index d28bf58..4fccc61 100644
--- a/meta-poky/conf/local.conf.sample
+++ b/meta-poky/conf/local.conf.sample
@@ -228,7 +228,7 @@ BB_DISKMON_DIRS ??= "\
 # present in the cache. It assumes you can download something faster than you 
can build it
 # which will depend on your network.
 #
-#SSTATE_MIRRORS ?= "file://.* 
http://sstate.yoctoproject.org/2.5/PATH;downloadfilename=PATH;
+#SSTATE_MIRRORS ?= "file://.* 
http://sstate.yoctoproject.org/dev/PATH;downloadfilename=PATH;
 
 #
 # Qemu configuration
-- 
2.19.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH][meta-yocto][thud] local.conf.sample: update upstream sstate mirror url

[Martin Hundebøll]

The prefilled upstream SSTATE_MIRROR setting in the sample configuration
should match the current Yocto release.

Signed-off-by: Martin Hundebøll 
---

Are we sure the sstate mirror is properly updated? I tried using it on
thud in a ubuntu-16.04 docker container, but wasn't able to get any hits
in the cache...

 meta-poky/conf/local.conf.sample | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-poky/conf/local.conf.sample b/meta-poky/conf/local.conf.sample
index d28bf58..fdeb424 100644
--- a/meta-poky/conf/local.conf.sample
+++ b/meta-poky/conf/local.conf.sample
@@ -228,7 +228,7 @@ BB_DISKMON_DIRS ??= "\
 # present in the cache. It assumes you can download something faster than you 
can build it
 # which will depend on your network.
 #
-#SSTATE_MIRRORS ?= "file://.* 
http://sstate.yoctoproject.org/2.5/PATH;downloadfilename=PATH;
+#SSTATE_MIRRORS ?= "file://.* 
http://sstate.yoctoproject.org/2.6/PATH;downloadfilename=PATH;
 
 #
 # Qemu configuration
-- 
2.19.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto