date:20180312

[yocto] [ANNOUNCEMENT] Yocto Project 2.4.2 (rocko-18.0.2) Released

2018-03-12 Thread Tracy Graydon

Hello,

The latest release of the Yocto Project 2.4.2 (rocko-18.0.2) is now available 
for download at:

http://downloads.yoctoproject.org/releases/yocto/yocto-2.4.2/poky-rocko-18.0.2.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.4.2/poky-rocko-18.0.2.tar.bz2

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

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

Full pass test report is available at:

https://wiki.yoctoproject.org/wiki/WW10_-_2018-03-05-_Full_Test_Cycle_-_2.4.2_rc2

Thank you to everyone for your contributions to this release!

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


--
yocto-2.4.2 Errata
--

Release Name: eclipse-poky-neon-rocko-18.0.2
Branch: neon/rocko
Tag: neon/rocko-18.0.2
Hash: a5dbc01b96be55c4ec2f774af9996a8086e402ab
md5: d2a5c651c5680ee3cf4d5f757787d580
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-2.4.2/eclipse-poky-neon-rocko-18.0.2.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.4.2/eclipse-poky-neon-rocko-18.0.2.tar.bz2

Release Name: eclipse-poky-oxygen-rocko-18.0.2
Branch: oxygen/rocko
Tag: oxygen/rocko-18.0.2
Hash: 020fc5814d2028654879356296b647002caf30b6
md5: e646e74bbee029b2545a558e097a5c84
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-2.4.2/eclipse-poky-oxygen-rocko-18.0.2.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.4.2/eclipse-poky-oxygen-rocko-18.0.2.tar.bz2

Release Name: meta-qt3-rocko-18.0.2
Branch: rocko
Tag: rocko-18.0.2
Hash: f33b73a9563f2dfdfd0ee37b61d65d90197a456f
md5: 4686bce6110b1c174423d04904e5b1ce
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-2.4.2/meta-qt3-rocko-18.0.2.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.4.2/meta-qt3-rocko-18.0.2.tar.bz2

Release Name: meta-qt4-rocko-18.0.2
Branch: rocko
Tag: rocko-18.0.2
Hash: f313dbee2ac3d5fcc9801407947d3cb6cfb90b5d
md5: 21ee0914b20dcdf9c665c231d3fd93c4
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-2.4.2/meta-qt4-rocko-18.0.2.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.4.2/meta-qt4-rocko-18.0.2.tar.bz2

Release Name: poky-rocko-18.0.2
Branch: rocko
Tag: rocko-18.0.2
Hash: 342fbd6a3e57021c8e28b124b3adb241936f3d9d
md5: 375ccb80a87771a5664ab170b1ae9d7d
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-2.4.2/poky-rocko-18.0.2.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.4.2/poky-rocko-18.0.2.tar.bz2


---
 Known Issues
---
https://bugzilla.yoctoproject.org/show_bug.cgi?id=12587

Runtime providers were sometimes changing order during builds, resulting in 
non-deterministic build results. 

Example:

DEBUG: providers for lib32-initd-functions are: ['lib32-lsbinitscripts', 
'lib32-initscripts']
or
DEBUG: providers for lib32-initd-functions are: ['lib32-initscripts', 
'lib32-lsbinitscripts']

This can lead to test failures.

This is fixed with Bitbake rev: 223a0f68530571d2280f526bddbc718fa803a3dc
This change ensures we don't rely on the random order of dictionaries in
memory and act deterministically. 

---
Security Fixes
---
glibc: Security fix CVE-2017-17426
glibc: Security Fix CVE-2017-16997
glibc: Security fix CVE-2017-15671
glibc: Security fix CVE-2017-15670


---
Fixes
---
glibc: Update to tip of 2.26
glibc: Adapt do_install_append_aarch64() for usrmerge
libtirpc: refresh patches
libtirpc: stop dropping in NIS headers
libunwind: Fix multilib header conflict - libunwind.h
libmpc: fix SRC_URI
siteinfo: add aarch64_illp32 decode
update-rc.d: QA regression.
webkitgtk_2.18.6.bb: Fix configure failure for aarch64 build
eglinfo-fb: Pass -DMESA_EGL_NO_X11_HEADERS to cxxflags
openssl: remove patch from 1.0.2m left behind after update to 1.0.2n
p11-kit: take source code from official git
meta-yocto-bsp: bump to the latest linux stable kernel for the non-x86 BSPs
linux-yocto: update genericx86* SRCREVs for v4.4
linux-yocto: update genericx86* SRCREVs for v4.9
linux-yocto: update genericx86* SRCREVs for v4.12
meta-yocto-bsp: bump to the latest linux stable kernel for the non-x86 BSPs
linux-yocto/4.12: fix qemuarm64 boot failure
kernel-yocto/4.9: update to v4.9.82
linux-yocto/4.12: update to v4.12.20
libc6: improve reproducibility
musl: Disable thumb1 ISA
musl: prevent errors if do_install is run more than once
musl: Update to 1.1.18
musl: Update to latest
gcc-7.3: Drop upstreamed musl cpuinfo patch
packagegroup-core-tools-profile: disable valgrind on armeb
webkitgtk: update to 2.18.6
linux-yocto/4.12: pinctrl backports
package_rpm.bbclass: Fix matching of architecture independent packages
openssl: update to 1.0.2n
openssl-ptest: improve reproducibility
build-appliance-image: Update to rocko head revision
poky.conf: Bump version for 2.4.2 rocko release
documentation: Updated Manual Revision Table for 2.4.2 Release Date
yocto-project-qs: Fixed spelling error in Welcome

Re: [yocto] extending HOSTTOOLS

2018-03-12 Thread Richard Purdie

On Fri, 2018-03-09 at 11:12 -0700, Oleg K Dzhimiev wrote:
> Poky 2.4.
> I would like to add ping and scp to HOSTTOOLS from a class inherited
> by a recipe. HOSTTOOLS is updated but the links will not appear in
> the build/tmp/hosttools/
> Is there any way to do this?

HOSTTOOLS is a global configuration option, its not per-recipe. You
therefore need to set it in the core distro config, not in a recipe.

Cheers,

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

[yocto] Benchmarking SDHC and SDIO driver

2018-03-12 Thread Udit agarwal

Hi community,
I am searching for any *widely* accepted benchmark, which can be used to
quantify performance of SDHC and SDIO drivers based on different
parameters, on embedded platforms?
Tests might include copying a block of data from host to a SD card or vice
versa and measuring bandwidth and speed available.

Any help/direction would be very helpful

Regards,
Udit agarwal
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Function failed: do_package_qa

2018-03-12 Thread Outback Dingo

On Mon, Mar 12, 2018 at 3:59 PM, Outback Dingo  wrote:
> -snip--

Okay ive confirmed this works, building fine again all the way through, thanks

>
> okay ive updated the makefile with your edits and read the doc, the
> new version is here... is it on the right track ??? much appreciated
> the insight
> modifications below
>
> #
> # This file was derived from the 'Hello World!' example recipe in the
> # Yocto Project Development Manual.
> #
>
> DESCRIPTION = "DLT Wrapper"
> SECTION = "libs"
> DEPENDS = "boost libusb1 dlt-daemon"
> LICENSE = "COMPANY_COMMON_LICENSES"
> LIC_FILES_CHKSUM =
> "file://${COMPANY_COMMON_LICENSES}/LICENSE;md5=18f1f6bf24836561f3a65cef19477d20"
>
> CFLAGS += "-std=gnu++14"
>
> inherit cmake
>
> # Use local tarball
> SRC_URI = "file://DLTWrapper.tgz"
>
> # The base package, this includes everything needed to actually run
> the application on the target system.
> PACKAGES += "FILES-${PN}-lib"
>
> FILES_${PN}-lib = "\
> ${libdir}/lib*.so.* \
> ${includedir}/*"
>
> # Make sure our source directory (for the build) matches the directory
> structure in the tarball
> S = "${WORKDIR}/DLTWrapper"
> PACKAGES = "${PN} FILES-${PN}-lib ${PN}-dev ${PN}-dbg ${PN}-staticdev"
>
> RDEPENDS_${PN}-staticdev = ""
> RDEPENDS_${PN}-dev = ""
> RDEPENDS_${PN}-dbg = ""
>
> INSANE_SKIP_${PN} = "ldflags"
> INHIBIT_PACKAGE_STRIP = "1"
> INHIBIT_SYSROOT_STRIP = "1"
> SOLIBS = ".so"
> FILES_SOLIBSDEV = ""
>
> do_install () {
> install -d ${D}${libdir}
> install -m 0755 ${WORKDIR}/libfoo.so ${D}${libdir}
> install -m 0755 ${WORKDIR}/DLTWrapper/include/* ${D}${includedir}
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Fwd: Integrating Ixxat SocketCAN Drivers in image

2018-03-12 Thread Vincent Daanen

Hi,

I have to integrate Ixxat SocketCAN driver in the image which will run our 
system.

The organisation of the files is the following
Yocto/MyCompany/meta-myCompany/recipes-candriver/ixxat-socketcan
This directory contains the file ixxat-socketcan.bb.
The content of this file is the following
SUMMARY = “…”
LICENSE = “CLOSED”
SRC_URI= 
https://www.ixxat.com/docs/librariesprovider8/default-document-library/downloads/other-drivers/socketcan.zip
SRC_URI[sha256sum] = «… »  (the sha256 sum is correct)
S=”${WORKDIR}”

The problems I run into are the following:
Although the recipe is found (it appears in the output of bitbake-layer 
show-recipe), and that the file is processed by bitbake (if I intentionally add 
a typo, the build breaks), it seems to not be processed (the zip file is not 
downloaded) when I invoke bitbake core-image-minimal..

When I invoke bitbake -b ixxat-socketcan, it fails with the following output 
(sorry for the formatting of the text)

ERROR: ixxat-socketcan-1.0-r0 do_unpack: Unpack failure for URL: 
'https://www.ixxat.com/docs/librariesprovider8/default-document-library/downloads/other-drivers/socketcan.zip'.
 Unpack command 
PATH="/home/rd-otx/yocto/RCU_Yocto/build-firstBoot/tmp/sysroots-uninative/x86_64-linux/usr/bin:/home/rd-otx/yocto/sources/poky/scripts:/home/rd-otx/yocto/RCU_Yocto/build-firstBoot/tmp/work/qemux86_64-poky-linux/ixxat-socketcan/1.0-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux:/home/rd-otx/yocto/RCU_Yocto/build-firstBoot/tmp/work/qemux86_64-poky-linux/ixxat-socketcan/1.0-r0/recipe-sysroot/usr/bin/crossscripts:/home/rd-otx/yocto/RCU_Yocto/build-firstBoot/tmp/work/qemux86_64-poky-linux/ixxat-socketcan/1.0-r0/recipe-sysroot-native/usr/sbin:/home/rd-otx/yocto/RCU_Yocto/build-firstBoot/tmp/work/qemux86_64-poky-linux/ixxat-socketcan/1.0-r0/recipe-sysroot-native/usr/bin:/home/rd-otx/yocto/RCU_Yocto/build-firstBoot/tmp/work/qemux86_64-poky-linux/ixxat-socketcan/1.0-r0/recipe-sysroot-native/sbin:/home/rd-otx/yocto/RCU_Yocto/build-firstBoot/tmp/work/qemux86_64-poky-linux/ixxat-socketcan/1.0-r0/recipe-sysroot-native/bin:/home/rd-otx/yocto/sources/poky-rocko-18.0.1/bitbake/bin:/home/rd-otx/yocto/RCU_Yocto/build-firstBoot/tmp/hosttools"
 unzip -q -o 
'/home/rd-otx/yocto/RCU_Yocto/build-firstBoot/downloads/socketcan.zip' failed 
with return value 127
ERROR: ixxat-socketcan-1.0-r0 do_unpack: Function failed: base_do_unpack
ERROR: Logfile of failure stored in: 
/home/rd-otx/yocto/RCU_Yocto/build-firstBoot/tmp/work/qemux86_64-poky-linux/ixxat-socketcan/1.0-r0/temp/log.do_unpack.16493
ERROR: ixxat-socketcan-1.0-r0 do_make_scripts: Function failed: do_make_scripts 
(log file is located at 
/home/rd-otx/yocto/RCU_Yocto/build-firstBoot/tmp/work/qemux86_64-poky-linux/ixxat-socketcan/1.0-r0/temp/log.do_make_scripts.16494)
ERROR: Task 
(/home/rd-otx/yocto/RCU_Yocto/meta-OtxLayer/recipes-candriver/ixxat-socketcan/ixxat-socketcan.bb:do_unpack)
 failed with exit code '1'
ERROR: Logfile of failure stored in: 
/home/rd-otx/yocto/RCU_Yocto/build-firstBoot/tmp/work/qemux86_64-poky-linux/ixxat-socketcan/1.0-r0/temp/log.do_make_scripts.16494

I found on the net that the first error is sometimes due to the 
fact that the archive file is corrupted but this is not the case. I could 
unpack the file manually using unzip .

Can someone point me to information or help me to figure out what’s wrong ??

Thanks

Vincent



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

[yocto] Integrating Ixxat SocketCAN Drivers in image

2018-03-12 Thread Vincent Daanen

Hi,

I have to integrate Ixxat SocketCAN driver in the image which will run our 
system.

The organisation of the files is the following
Yocto/MyCompany/meta-myCompany/recipes-candriver/ixxat-socketcan
This directory contains the file ixxat-socketcan.bb.
The content of this file is the following
SUMMARY = "..."
LICENSE = "CLOSED"
SRC_URI= 
https://www.ixxat.com/docs/librariesprovider8/default-document-library/downloads/other-drivers/socketcan.zip
SRC_URI[sha256sum] = <... >  (the sha256 sum is correct)
S="${WORKDIR}"

The problems I run into are the following:

  1.  Although the recipe is found (it appears in the output of bitbake-layer 
show-recipe), and that the file is processed by bitbake (if I intentionally add 
a typo, the build breaks), it seems to not be processed (the zip file is not 
downloaded) when I invoke bitbake core-image-minimal..



  1.  When I invoke bitbake -b ixxat-socketcan, it fails with the following 
output (sorry for the formatting of the text)



ERROR: ixxat-socketcan-1.0-r0 do_unpack: Unpack failure for URL: 
'https://www.ixxat.com/docs/librariesprovider8/default-document-library/downloads/other-drivers/socketcan.zip'.
 Unpack command 
PATH="/home/rd-otx/yocto/RCU_Yocto/build-firstBoot/tmp/sysroots-uninative/x86_64-linux/usr/bin:/home/rd-otx/yocto/sources/poky/scripts:/home/rd-otx/yocto/RCU_Yocto/build-firstBoot/tmp/work/qemux86_64-poky-linux/ixxat-socketcan/1.0-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux:/home/rd-otx/yocto/RCU_Yocto/build-firstBoot/tmp/work/qemux86_64-poky-linux/ixxat-socketcan/1.0-r0/recipe-sysroot/usr/bin/crossscripts:/home/rd-otx/yocto/RCU_Yocto/build-firstBoot/tmp/work/qemux86_64-poky-linux/ixxat-socketcan/1.0-r0/recipe-sysroot-native/usr/sbin:/home/rd-otx/yocto/RCU_Yocto/build-firstBoot/tmp/work/qemux86_64-poky-linux/ixxat-socketcan/1.0-r0/recipe-sysroot-native/usr/bin:/home/rd-otx/yocto/RCU_Yocto/build-firstBoot/tmp/work/qemux86_64-poky-linux/ixxat-socketcan/1.0-r0/recipe-sysroot-native/sbin:/home/rd-otx/yocto/RCU_Yocto/build-firstBoot/tmp/work/qemux86_64-poky-linux/ixxat-socketcan/1.0-r0/recipe-sysroot-native/bin:/home/rd-otx/yocto/sources/poky-rocko-18.0.1/bitbake/bin:/home/rd-otx/yocto/RCU_Yocto/build-firstBoot/tmp/hosttools"
 unzip -q -o 
'/home/rd-otx/yocto/RCU_Yocto/build-firstBoot/downloads/socketcan.zip' failed 
with return value 127

ERROR: ixxat-socketcan-1.0-r0 do_unpack: Function failed: base_do_unpack

ERROR: Logfile of failure stored in: 
/home/rd-otx/yocto/RCU_Yocto/build-firstBoot/tmp/work/qemux86_64-poky-linux/ixxat-socketcan/1.0-r0/temp/log.do_unpack.16493

ERROR: ixxat-socketcan-1.0-r0 do_make_scripts: Function failed: do_make_scripts 
(log file is located at 
/home/rd-otx/yocto/RCU_Yocto/build-firstBoot/tmp/work/qemux86_64-poky-linux/ixxat-socketcan/1.0-r0/temp/log.do_make_scripts.16494)

ERROR: Task 
(/home/rd-otx/yocto/RCU_Yocto/meta-OtxLayer/recipes-candriver/ixxat-socketcan/ixxat-socketcan.bb:do_unpack)
 failed with exit code '1'

ERROR: Logfile of failure stored in: 
/home/rd-otx/yocto/RCU_Yocto/build-firstBoot/tmp/work/qemux86_64-poky-linux/ixxat-socketcan/1.0-r0/temp/log.do_make_scripts.16494


I found on the net that the first error is sometimes due to the 
fact that the archive file is corrupted but this is not the case. I could 
unpack the file manually using unzip .

Can someone point me to information or help me to figure out what's wrong ??

Thanks

Vincent

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

[yocto] [meta-java][PATCH 2/2] openjdk-8: fix build with --as-needed host toolchains (Ubuntu 16.04)

2018-03-12 Thread André Draszik

From: André Draszik 

As per the commit message - build on hosts with --as-needed
toolchains (Ubuntu 16.04) using system provided zlib fails:

If the (host) toolchain has been configured to
unconditionally add --as-needed to the linker command line
then linking can fail when using system libraries.

The reason is that the order of command line arguments
becomes important with --as-needed and the JDK build system
places needed system libraries at the beginning of the
command line where it would normally place the object files
from its own bundled compiled version.

Having those system libraries early in the command line is
not useful, as they are discarded by the linker at that
point in time as it hasn't seen any reference to the
symbols provided yet.

As it seems a generic pattern in the makefiles here, just
place the $EXPECTED_OBJS early in the command line, before
any additional libraries, so as to fix this once and for
all.

Change-Id: I568067011bb8899700c63aa3ee9ca952045cce05
Signed-off-by: André Draszik 
---
 recipes-core/openjdk/openjdk-8-release-16xbyy.inc  |  1 +
 ...fix-build-on-as-needed-toolchains-generic.patch | 91 ++
 2 files changed, 92 insertions(+)
 create mode 100644 
recipes-core/openjdk/patches-openjdk-8/0010-build-fix-build-on-as-needed-toolchains-generic.patch

diff --git a/recipes-core/openjdk/openjdk-8-release-16xbyy.inc 
b/recipes-core/openjdk/openjdk-8-release-16xbyy.inc
index ab72830..bd4a349 100644
--- a/recipes-core/openjdk/openjdk-8-release-16xbyy.inc
+++ b/recipes-core/openjdk/openjdk-8-release-16xbyy.inc
@@ -15,6 +15,7 @@ PATCHES_URI = "\
 file://0007-jdk-use-correct-include-for-poll.patch \
 file://0008-jdk-use-correct-include-for-signal.patch \
 file://0009-jdk-disable-backtrace-musl-build-fix.patch \
+file://0010-build-fix-build-on-as-needed-toolchains-generic.patch \
 "
 # some patches extracted from 
http://cr.openjdk.java.net/~rkennke/shark-build-hotspot/webrev.01/hotspot.patch
 # reported via 
http://mail.openjdk.java.net/pipermail/build-dev/2015-January/013972.html
diff --git 
a/recipes-core/openjdk/patches-openjdk-8/0010-build-fix-build-on-as-needed-toolchains-generic.patch
 
b/recipes-core/openjdk/patches-openjdk-8/0010-build-fix-build-on-as-needed-toolchains-generic.patch
new file mode 100644
index 000..2d02b7c
--- /dev/null
+++ 
b/recipes-core/openjdk/patches-openjdk-8/0010-build-fix-build-on-as-needed-toolchains-generic.patch
@@ -0,0 +1,91 @@
+From 84bcdb9cdab0e0be9cdfededfb518d3cea9009e3 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Andr=C3=A9=20Draszik?= 
+Date: Mon, 12 Mar 2018 15:40:58 +
+Subject: [PATCH] build: fix build on --as-needed toolchains (generic)
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+If the (host) toolchain has been configured to
+unconditionally add --as-needed to the linker command line
+then linking fails when using the system zlib:
+  + ...gcc -lz -L/usr/lib -L/lib \
+   -Wl,-rpath-link,/usr/lib -Wl,-rpath-link,/lib 
\
+   -Wl,-rpath,/usr/lib -Wl,-rpath,/lib \
+   -Wl,-O1 -Xlinker --hash-style=both -Xlinker -z -Xlinker defs 
-Xlinker -O1 \
+   -Xlinker --allow-shlib-undefined -Xlinker -soname=libunpack.so \
+   -Xlinker -z -Xlinker origin -Xlinker -rpath -Xlinker '$ORIGIN' \
+   -lc \
+   -Xlinker 
-version-script=/jdk/make/mapfiles/libunpack/mapfile-vers-unpack200 \
+   -o $build/jdk/objs/unpackexe/unpack200 \
+   $build/jdk/objs/unpackexe/bands.o $build/jdk/objs/unpackexe/bytes.o 
\
+   $build/jdk/objs/unpackexe/coding.o $build/jdk/objs/unpackexe/main.o 
\
+   $build/jdk/objs/unpackexe/unpack.o 
$build/jdk/objs/unpackexe/utils.o \
+   $build/jdk/objs/unpackexe/zip.o -lstdc++
+  $build/jdk/objs/unpackexe/zip.o: In function `jar::deflate_bytes(bytes&, 
bytes&)':
+  $src/jdk/src/share/native/com/sun/java/util/jar/pack/zip.cpp:464: undefined 
reference to `deflateInit2_'
+  $src/jdk/src/share/native/com/sun/java/util/jar/pack/zip.cpp:507: undefined 
reference to `deflate'
+  $src/jdk/src/share/native/com/sun/java/util/jar/pack/zip.cpp:514: undefined 
reference to `deflateEnd'
+  $src/jdk/src/share/native/com/sun/java/util/jar/pack/zip.cpp:502: undefined 
reference to `deflate'
+  $src/jdk/src/share/native/com/sun/java/util/jar/pack/zip.cpp:518: undefined 
reference to `deflateEnd'
+  $build/jdk/objs/unpackexe/zip.o: In function `jar::get_crc32(unsigned int, 
unsigned char*, unsigned int)':
+  $src/jdk/src/share/native/com/sun/java/util/jar/pack/zip.cpp:61: undefined 
reference to `crc32'
+  $src/jdk/src/share/native/com/sun/java/util/jar/pack/zip.cpp:61: undefined 
reference to `crc32'
+  $src/jdk/src/share/native/com/sun/java/util/jar/pack/zip.cpp:61: undefined 
reference to `crc32'
+  $build/jdk/objs/unpackexe/zip.o: In function `gunzip::free()':
+

[yocto] [meta-java][PATCH 1/2] openjdk-8: fix MAKE detection patch

2018-03-12 Thread André Draszik

From: André Draszik 

The patch had a few typos, leading to errors during ./configure
   ../jdk8u-4be07cb28b21/common/autoconf/configure: line 8408: test: too many 
arguments

Change-Id: I867eba7aae3390aa869e69c86f29e77b505043e7
---
 recipes-core/openjdk/patches-openjdk-8/dont-expect-fqpn-for-make.patch | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/recipes-core/openjdk/patches-openjdk-8/dont-expect-fqpn-for-make.patch 
b/recipes-core/openjdk/patches-openjdk-8/dont-expect-fqpn-for-make.patch
index 6454237..5192d1a 100644
--- a/recipes-core/openjdk/patches-openjdk-8/dont-expect-fqpn-for-make.patch
+++ b/recipes-core/openjdk/patches-openjdk-8/dont-expect-fqpn-for-make.patch
@@ -6,7 +6,7 @@
  # User has supplied a make, test it.
 -if test ! -f "$MAKE"; then
 -  AC_MSG_ERROR([The specified make (by MAKE=$MAKE) is not found.])
-+if test -a `dirname "$MAKE"` = "." -a ! -f "$MAKE"; then
++if test `dirname "$MAKE"` = "." && ! test -f "$MAKE"; then
 +  AC_PATH_PROGS(CHECK_MAKE, $MAKE)
 +else
 +  CHECK_MAKE="${MAKE}"
-- 
2.16.2

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

[yocto] IMPORTANT: do_patch() fuzz warnings and how to deal with them

2018-03-12 Thread Alexander Kanavin


*Executive summary*

do_patch() will shortly start issuing warnings when recipe patches are 
applied with some of the patch context ignored. This email explains why 
this is necessary, and how the warnings can be eliminated.


*What is patch fuzz?*

Patch fuzz is a situation when the patch tool ignores some of the 
context lines in order to apply the patch. Consider this example:


Patch to be applied:


context line 1
context line 2
context line 3
+newly added line
context line 4
context line 5
context line 6


Original source code:


different context line 1
different context line 2
context line 3
context line 4
different context line 5
different context line 6


Outcome:


different context line 1
different context line 2
context line 3
newly added line
context line 4
different context line 5
different context line 6


Chances are, the newly added line was actually added in a completely 
wrong location, or it was already in the original source, and was added 
for the second time. This is especially possible, if the context line 3 
and 4 are blank or have only generic things in them like #endif or }. 
Even worse, there is currently no warning when this happens, and 
depending on the patched code, it can (and does) still compile without 
errors.


*What is changing*

When patch fuzz is detected, there will be a warning printed, similar to 
this:


WARNING: vulkan-1.0.61.1-r0 do_patch:
Some of the context lines in patches were ignored. This can lead to 
incorrectly applied patches.

The context lines in the patches can be updated with devtool:

devtool modify 
devtool finish --force-patch-refresh  

Then the updated patches and the source tree (in devtool's workspace)
should be reviewed to make sure the patches apply in the correct place
and don't introduce duplicate lines (which can, and does happen
when some of the context is ignored).
Details:
Applying patch demos-Don-t-build-tri-or-cube.patch
patching file demos/CMakeLists.txt
Hunk #1 succeeded at 63 (offset 2 lines).
Hunk #2 succeeded at 76 with fuzz 1 (offset 2 lines).

*How to elimimate the warnings?*

Use devtool command as explained by the warning. First, unpack the 
source into devtool workspace:


devtool modify 

This will apply all the patches, and create new commits out of them in 
the workspace - with the patch context updated.


Then, replace the patches in the recipe layer:

devtool finish --force-patch-refresh  

The patch updates need be reviewed (preferably, with a side-by-side diff 
tool) to ensure they are indeed doing the right thing:


1) they get applied in the correct location;
2) they do not introduce duplicate lines, or otherwise do things that 
are not anymore necessary.


To confirm these things, you can also review the patched source code in 
devtool's workspace, typically in /workspace/sources//


Once the review is done, you can create and publish a layer commit with 
the patch updates that modify the context. Devtool may also refresh 
other things in the patches, those can be discarded.



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

[yocto] Yocto Project Status WW11’18

2018-03-12 Thread Jordan, Robin L

Current Dev Position: YP 2.5 M3 final close out.

Next Deadline: YP 2.5 M3 cut off was 2/19/18

*** FEATURE FREEZE for 2.5 has passed ***


SWAT lead is currently Cal.

SWAT team rotation: Cal -> Armin on March 16, 2018

SWAT team rotation: Armin -> Ross on March 23, 2018

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


Key Status/Updates:

  *   The Embedded Linux Conference is in Portland this week!
  *   YP 2.4.2 RC2 QA report is being discussed and is expected to be released 
this week. 
(https://wiki.yoctoproject.org/wiki/WW10_-_2018-03-05-_Full_Test_Cycle_-_2.4.2_rc2).
  *   We are changing the planning process and Milestone tracking in Bugzilla.  
More details can be found here:  
https://lists.yoctoproject.org/pipermail/yocto/2018-March/040226.html
  *   A new uninative release was made (1.8) because distributions are moving 
to glibc 2.27 and this broke the old uninative. People using uninative should 
upgrade to this.
  *   GCC 6.x with the latest security fixes is currently in rocko/pyro/morty 
-next thanks to Martin and Juro. They are undergoing autobuilder testing now 
but we hope they’ll be merged soon.

  *   Performance metrics indicate that a recent merge has caused a slowdown in 
build times.  It is suspected that the glibc upgrade is the cause of this 
although help would be appreciated to verify and possibly mitigate this.
  *   Flood of last-minute upgrades continuing to be reviewed and merged if 
high reward or low impact.
  *   Go upgrade/improvements were merged.  For 2.5 we will be shipping both 
1.9.4 and 1.10, but plan to drop 1.9.x from master once 1.10 doesn’t present 
compatibility problems.
  *   EFI image refactoring patches were merged. The gist of these are that 
/boot is now under package manager control instead of injected at image 
creation.
  *   A number of patch refresh patches were merged. These are to solve 
problems with patches applied with “fuzz”, where patch will note that the 
context isn’t correct anymore but the differences are hopefully small enough to 
apply anyway.  Sometimes this is useful (other changes causing the target lines 
to move), sometimes it’s actively harmful (patch applied incorrectly, silently 
breaking behaviour). We hope to warn when fuzz is detected during the 2.6 cycle 
so these patches are removing fuzz from oe-core.  Expect a mail to the lists 
soon explaining how to find and remove fuzz.
  *   We are continuing to work on the autobuilder changes and for various 
reasons (inc. changes in people).  We would be in much better shape to switch 
to the new codebase before release, rather than waiting until early 2.6 to pick 
this work up again by which time we would have lost people and context. If we 
are to switch, we need to build M3 with the new infrastructure. We plan to make 
this switch for M3.


Planned upcoming dot releases:

YP 2.3.4 (Pyro) will be built when GCC backports are merged.

YP 2.2.4 (Morty) will be built when GCC backports are merged.

YP 2.4.3 (Roko) is planned for post YP 2.5.


Key YP 2.5 Dates are:

YP 2.5 M3 is in feature freeze.  See status above.

YP 2.5 M3 was scheduled for release 3/2/18

YP 2.5 M4 cut off of 4/2/18

YP 2.5 M4 release of 4/27/18


Tracking Metrics:

WDD 2673 (last week 2663)

(https://wiki.yoctoproject.org/charts/combo.html)


Key Status Links for YP:

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

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

https://wiki.yoctoproject.org/wiki/Yocto_2.5_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!]


Robin Jordan
Yocto Project Program Manager
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Function failed: do_package_qa

2018-03-12 Thread Outback Dingo

-snip--

okay ive updated the makefile with your edits and read the doc, the
new version is here... is it on the right track ??? much appreciated
the insight
modifications below

#
# This file was derived from the 'Hello World!' example recipe in the
# Yocto Project Development Manual.
#

DESCRIPTION = "DLT Wrapper"
SECTION = "libs"
DEPENDS = "boost libusb1 dlt-daemon"
LICENSE = "COMPANY_COMMON_LICENSES"
LIC_FILES_CHKSUM =
"file://${COMPANY_COMMON_LICENSES}/LICENSE;md5=18f1f6bf24836561f3a65cef19477d20"

CFLAGS += "-std=gnu++14"

inherit cmake

# Use local tarball
SRC_URI = "file://DLTWrapper.tgz"

# The base package, this includes everything needed to actually run
the application on the target system.
PACKAGES += "FILES-${PN}-lib"

FILES_${PN}-lib = "\
${libdir}/lib*.so.* \
${includedir}/*"

# Make sure our source directory (for the build) matches the directory
structure in the tarball
S = "${WORKDIR}/DLTWrapper"
PACKAGES = "${PN} FILES-${PN}-lib ${PN}-dev ${PN}-dbg ${PN}-staticdev"

RDEPENDS_${PN}-staticdev = ""
RDEPENDS_${PN}-dev = ""
RDEPENDS_${PN}-dbg = ""

INSANE_SKIP_${PN} = "ldflags"
INHIBIT_PACKAGE_STRIP = "1"
INHIBIT_SYSROOT_STRIP = "1"
SOLIBS = ".so"
FILES_SOLIBSDEV = ""

do_install () {
install -d ${D}${libdir}
install -m 0755 ${WORKDIR}/libfoo.so ${D}${libdir}
install -m 0755 ${WORKDIR}/DLTWrapper/include/* ${D}${includedir}
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Function failed: do_package_qa

2018-03-12 Thread Burton, Ross

On 12 March 2018 at 13:35, Outback Dingo  wrote:

> Well heres the dltwrapper bb file it appears to build fine
> #
> # This file was derived from the 'Hello World!' example recipe in the
> # Yocto Project Development Manual.
> #
>
> DESCRIPTION = "DLT Wrapper"
> SECTION = "examples"
> DEPENDS = "boost libusb1 dlt-daemon"
> LICENSE = "COMPANY_COMMON_LICENSES"
> LIC_FILES_CHKSUM =
> "file://${COMPANY_COMMON_LICENSES}/LICENSE;md5=
> 18f1f6bf24836561f3a65cef19477d20"
>
> TARGET_CFLAGS += "-std=gnu++14"
>
> Just use CFLAGS


> # This tells bitbake where to find the files we're providing on the
> local filesystem
> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>

Redundant, remove this


> FILES_${PN} += "${includedir}/*"
>

Wrong, includedir goes into PN-dev.  This is the default, so remove this.


> inherit autotools gettext cmake
>

Does DLT wrapper use autotools or cmake? It can't use both.  Does it need
to inherit gettext?


> do_install() {
> install -d ${D}${libdir}
> install -d ${D}${includedir}
> install -m 0755 ${WORKDIR}/build/libDLTWrapper.so ${D}${libdir}
> install -m 0755 ${WORKDIR}/DLTWrapper/include/* ${D}${includedir}
> }
>

Presumably you're doing this because the autotools or cmake files in your
tarball doesn't have an install target?

Anyway, that's the problem.  You're installing an unversioned .so file
which will be put into PN-dev by default.  Unversioned libraries are
frowned upon but if you can't change it then the wiki has a guide:

https://wiki.yoctoproject.org/wiki/TipsAndTricks/Packaging_Prebuilt_Libraries#Non-versioned_Libraries

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

Re: [yocto] Function failed: do_package_qa

2018-03-12 Thread Outback Dingo

Well heres the dltwrapper bb file it appears to build fine
#
# This file was derived from the 'Hello World!' example recipe in the
# Yocto Project Development Manual.
#

DESCRIPTION = "DLT Wrapper"
SECTION = "examples"
DEPENDS = "boost libusb1 dlt-daemon"
LICENSE = "COMPANY_COMMON_LICENSES"
LIC_FILES_CHKSUM =
"file://${COMPANY_COMMON_LICENSES}/LICENSE;md5=18f1f6bf24836561f3a65cef19477d20"

TARGET_CFLAGS += "-std=gnu++14"

# This tells bitbake where to find the files we're providing on the
local filesystem
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
FILES_${PN} += "${includedir}/*"
inherit autotools gettext cmake
# Use local tarball
SRC_URI = "file://DLTWrapper.tgz"

# Make sure our source directory (for the build) matches the directory
structure in the tarball
S = "${WORKDIR}/DLTWrapper"

do_install() {
install -d ${D}${libdir}
install -d ${D}${includedir}
install -m 0755 ${WORKDIR}/build/libDLTWrapper.so ${D}${libdir}
install -m 0755 ${WORKDIR}/DLTWrapper/include/* ${D}${includedir}
}

On Mon, Mar 12, 2018 at 12:58 PM, Burton, Ross  wrote:
> At a guess as I don't have any of your recipes to look at, jsonparser and
> dltwrapper packages are broken and putting the libraries into the -dev
> packages.  That probably caused a QA warning too.
>
> Ross
>
> On 12 March 2018 at 11:53, Outback Dingo  wrote:
>>
>> ERROR: QA Issue: r4-hub rdepends on dltwrapper-dev [dev-deps]
>> ERROR: QA Issue: r4-hub rdepends on jsonparser-dev [dev-deps]
>> ERROR: QA run found fatal errors. Please consider fixing them.
>> ERROR: Function failed: do_package_qa
>> ERROR: Logfile of failure stored in: log.do_package_qa.21297
>>
>> seems ive created a bitbake recipe, which depends on a couple of
>> libraries to be built, so i created the bitbake for the libs and all
>> appears to build fine, however seeing the failure above its basically
>> telling me something isnt being created during the packaging process
>> for the libs to be properly included in the image, they does exist a
>> pkgname-dev.ipkg for each of the libs but not a packagename.ipkg ...
>> any ideas... its kind of holding me up at this point.
>> --
>> ___
>> 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] Function failed: do_package_qa

2018-03-12 Thread Burton, Ross

At a guess as I don't have any of your recipes to look at, jsonparser and
dltwrapper packages are broken and putting the libraries into the -dev
packages.  That probably caused a QA warning too.

Ross

On 12 March 2018 at 11:53, Outback Dingo  wrote:

> ERROR: QA Issue: r4-hub rdepends on dltwrapper-dev [dev-deps]
> ERROR: QA Issue: r4-hub rdepends on jsonparser-dev [dev-deps]
> ERROR: QA run found fatal errors. Please consider fixing them.
> ERROR: Function failed: do_package_qa
> ERROR: Logfile of failure stored in: log.do_package_qa.21297
>
> seems ive created a bitbake recipe, which depends on a couple of
> libraries to be built, so i created the bitbake for the libs and all
> appears to build fine, however seeing the failure above its basically
> telling me something isnt being created during the packaging process
> for the libs to be properly included in the image, they does exist a
> pkgname-dev.ipkg for each of the libs but not a packagename.ipkg ...
> any ideas... its kind of holding me up at this point.
> --
> ___
> 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] Function failed: do_package_qa

2018-03-12 Thread Outback Dingo

ERROR: QA Issue: r4-hub rdepends on dltwrapper-dev [dev-deps]
ERROR: QA Issue: r4-hub rdepends on jsonparser-dev [dev-deps]
ERROR: QA run found fatal errors. Please consider fixing them.
ERROR: Function failed: do_package_qa
ERROR: Logfile of failure stored in: log.do_package_qa.21297

seems ive created a bitbake recipe, which depends on a couple of
libraries to be built, so i created the bitbake for the libs and all
appears to build fine, however seeing the failure above its basically
telling me something isnt being created during the packaging process
for the libs to be properly included in the image, they does exist a
pkgname-dev.ipkg for each of the libs but not a packagename.ipkg ...
any ideas... its kind of holding me up at this point.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] O_RDONLY ... missed bits/fcntl.h not as expected

2018-03-12 Thread Burton, Ross

On 12 March 2018 at 11:34, Arno Steffens  wrote:

> You are right,  the bits/fcntl-32.h at the very end has a
> #include 
> But, all lines in  are greyed (not active), except these I
> noted as bold (below). So it not become active.
> I would assume __arm__ should be set by someone.
>
> It seems it is not a problem for the compiler, but for the Eclipse viewer
> to show the code.
> That is the problem here.  I try to set ARCH=arm at various places in
> eclipse. but id doesn't have an effect.
> Mhh.
>

gcc will be setting that.  If Eclipse is doing something wrong, then blame
eclipse.

gcc -dM -E - < /dev/null will list the preprocessor symbols that are
internally defined.

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

Re: [yocto] O_RDONLY ... missed bits/fcntl.h not as expected

2018-03-12 Thread Arno Steffens



You are right,  the bits/fcntl-32.h at the very end has a

#include 


But, all lines in  are greyed (not active), except these I noted as bold (below). So it not become active.

I would assume __arm__ should be set by someone.
 

It seems it is not a problem for the compiler, but for the Eclipse viewer to show the code.


That is the problem here.  I try to set ARCH=arm at various places in eclipse. but id doesn't have an effect.

Mhh.


 

Gesendet: Montag, 12. März 2018 um 11:39 Uhr
Von: "Burton, Ross" 
An: "Arno Steffens" 
Cc: Yocto-mailing-list 
Betreff: Re: Re: [yocto] O_RDONLY ... missed bits/fcntl.h not as expected


Have you looked at the content of bits/fcntl-32.h?

 
On 12 March 2018 at 10:32, Arno Steffens  wrote:




 

Sure, sorry if this wasn't clear.

For me the chain is

 includes   (see below) and this doesn't include .

This is my SDK sysroot for cortexa9-hf.

 

Arno

 

 


/*
 * Copyright (C) 2005-2011 by Wind River Systems, Inc.
 *
 * Permission is hereby granted, free of charge, to any person obtaining a copy
 * of this software and associated documentation files (the "Software"), to deal
 * in the Software without restriction, including without limitation the rights
 * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
 * copies of the Software, and to permit persons to whom the Software is
 * furnished to do so, subject to the following conditions:
 *
 * The above copyright notice and this permission notice shall be included in
 * all copies or substantial portions of the Software.
 *
 * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
 * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
 * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
 * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
 * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
 * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
 * THE SOFTWARE.
 *
 */


#if defined (__arm__)
#define __MHWORDSIZE            32
#elif defined (__aarch64__) && defined ( __LP64__)
#define __MHWORDSIZE            64
#elif defined (__aarch64__)
#define __MHWORDSIZE            32
#else
#include 
#if defined (__WORDSIZE)
#define __MHWORDSIZE            __WORDSIZE
#else
#error "__WORDSIZE is not defined"
#endif
#endif

#if __MHWORDSIZE == 32

#ifdef _MIPS_SIM

#if _MIPS_SIM == _ABIO32
#include 
#elif _MIPS_SIM == _ABIN32
#include 
#else
#error "Unknown _MIPS_SIM"
#endif

#else /* _MIPS_SIM is not defined */
#include 
#endif

#elif __MHWORDSIZE == 64
#include 
#else
#error "Unknown __WORDSIZE detected"
#endif /* matches #if __WORDSIZE == 32 */
 

 

 


Gesendet: Montag, 12. März 2018 um 11:00 Uhr
Von: "Burton, Ross" 
An: "Arno Steffens" 
Cc: Yocto-mailing-list 
Betreff: Re: [yocto] O_RDONLY ... missed bits/fcntl.h not as expected




Can you explain what the actual problem is?
 

For me the include you'd use in programs  includes  which includes  which defines O_RDONLY.

 

Ross

 


 
On 12 March 2018 at 07:32, Arno Steffens  wrote:

I looked for
#define O_RDONLY             00
#define O_WRONLY             01
#define O_RDWR               02
and found it in : bits/fcntl-linux.h. According to this file it should not be included, but bits/fcntl.h.
And it requires something like that:

  A minimal  contains just:
   struct flock {...}
   #ifdef __USE_LARGEFILE64
   struct flock64 {...}
   #endif
   #include 



But this doesn't finally include the fcntl-linux.h as expected. Am I doing something wrong?
Regards
Arno



--
___
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] O_RDONLY ... missed bits/fcntl.h not as expected

2018-03-12 Thread Burton, Ross

Have you looked at the content of bits/fcntl-32.h?

On 12 March 2018 at 10:32, Arno Steffens  wrote:

>
> Sure, sorry if this wasn't clear.
> For me the chain is
>  includes   (see below) and this doesn't include
> .
> This is my SDK sysroot for cortexa9-hf.
>
> Arno
>
>
> /*
>  * Copyright (C) 2005-2011 by Wind River Systems, Inc.
>  *
>  * Permission is hereby granted, free of charge, to any person obtaining a
> copy
>  * of this software and associated documentation files (the "Software"),
> to deal
>  * in the Software without restriction, including without limitation the
> rights
>  * to use, copy, modify, merge, publish, distribute, sublicense, and/or
> sell
>  * copies of the Software, and to permit persons to whom the Software is
>  * furnished to do so, subject to the following conditions:
>  *
>  * The above copyright notice and this permission notice shall be included
> in
>  * all copies or substantial portions of the Software.
>  *
>  * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
> OR
>  * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
>  * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> THE
>  * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
>  * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> FROM,
>  * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
> IN
>  * THE SOFTWARE.
>  *
>  */
>
> #if defined (__arm__)
> #define __MHWORDSIZE32
> #elif defined (__aarch64__) && defined ( __LP64__)
> #define __MHWORDSIZE64
> #elif defined (__aarch64__)
> #define __MHWORDSIZE32
> #else
> #include 
> #if defined (__WORDSIZE)
> #define __MHWORDSIZE__WORDSIZE
> #else
> #error "__WORDSIZE is not defined"
> #endif
> #endif
> #if __MHWORDSIZE == 32
> #ifdef _MIPS_SIM
> #if _MIPS_SIM == _ABIO32
> #include 
> #elif _MIPS_SIM == _ABIN32
> #include 
> #else
> #error "Unknown _MIPS_SIM"
> #endif
> #else /* _MIPS_SIM is not defined */
> #include 
> #endif
> #elif __MHWORDSIZE == 64
> #include 
> #else
> #error "Unknown __WORDSIZE detected"
> #endif /* matches #if __WORDSIZE == 32 */
>
>
>
> *Gesendet:* Montag, 12. März 2018 um 11:00 Uhr
> *Von:* "Burton, Ross" 
> *An:* "Arno Steffens" 
> *Cc:* Yocto-mailing-list 
> *Betreff:* Re: [yocto] O_RDONLY ... missed bits/fcntl.h not as expected
> Can you explain what the actual problem is?
>
> For me the include you'd use in programs  includes 
> which includes  which defines O_RDONLY.
>
> Ross
>
>
> On 12 March 2018 at 07:32, Arno Steffens  wrote:
>>
>> I looked for
>> #define O_RDONLY 00
>> #define O_WRONLY 01
>> #define O_RDWR   02
>> and found it in : bits/fcntl-linux.h. According to this file it should
>> not be included, but bits/fcntl.h.
>> And it requires something like that:
>>
>>   A minimal  contains just:
>>struct flock {...}
>>#ifdef __USE_LARGEFILE64
>>struct flock64 {...}
>>#endif
>>#include 
>>
>>
>>
>> But this doesn't finally include the fcntl-linux.h as expected. Am I
>> doing something wrong?
>> Regards
>> Arno
>>
>>
>>
>> --
>> ___
>> 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] O_RDONLY ... missed bits/fcntl.h not as expected

2018-03-12 Thread Arno Steffens

 

Sure, sorry if this wasn't clear.

For me the chain is

 includes   (see below) and this doesn't include .

This is my SDK sysroot for cortexa9-hf.

 

Arno

 

 


/*
 * Copyright (C) 2005-2011 by Wind River Systems, Inc.
 *
 * Permission is hereby granted, free of charge, to any person obtaining a copy
 * of this software and associated documentation files (the "Software"), to deal
 * in the Software without restriction, including without limitation the rights
 * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
 * copies of the Software, and to permit persons to whom the Software is
 * furnished to do so, subject to the following conditions:
 *
 * The above copyright notice and this permission notice shall be included in
 * all copies or substantial portions of the Software.
 *
 * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
 * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
 * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
 * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
 * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
 * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
 * THE SOFTWARE.
 *
 */


#if defined (__arm__)
#define __MHWORDSIZE            32
#elif defined (__aarch64__) && defined ( __LP64__)
#define __MHWORDSIZE            64
#elif defined (__aarch64__)
#define __MHWORDSIZE            32
#else
#include 
#if defined (__WORDSIZE)
#define __MHWORDSIZE            __WORDSIZE
#else
#error "__WORDSIZE is not defined"
#endif
#endif

#if __MHWORDSIZE == 32

#ifdef _MIPS_SIM

#if _MIPS_SIM == _ABIO32
#include 
#elif _MIPS_SIM == _ABIN32
#include 
#else
#error "Unknown _MIPS_SIM"
#endif

#else /* _MIPS_SIM is not defined */
#include 
#endif

#elif __MHWORDSIZE == 64
#include 
#else
#error "Unknown __WORDSIZE detected"
#endif /* matches #if __WORDSIZE == 32 */
 

 

 


Gesendet: Montag, 12. März 2018 um 11:00 Uhr
Von: "Burton, Ross" 
An: "Arno Steffens" 
Cc: Yocto-mailing-list 
Betreff: Re: [yocto] O_RDONLY ... missed bits/fcntl.h not as expected


Can you explain what the actual problem is?
 

For me the include you'd use in programs  includes  which includes  which defines O_RDONLY.

 

Ross

 


 
On 12 March 2018 at 07:32, Arno Steffens  wrote:

I looked for
#define O_RDONLY             00
#define O_WRONLY             01
#define O_RDWR               02
and found it in : bits/fcntl-linux.h. According to this file it should not be included, but bits/fcntl.h.
And it requires something like that:

  A minimal  contains just:
   struct flock {...}
   #ifdef __USE_LARGEFILE64
   struct flock64 {...}
   #endif
   #include 



But this doesn't finally include the fcntl-linux.h as expected. Am I doing something wrong?
Regards
Arno



--
___
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] python-pyqt

2018-03-12 Thread Alan Martinovic

Don't know if I can help you with that, sorry.
Seems to be a promise of a nest of snakes :)

Perhaps a suggestion before you go down that rabbit hole...
Try getting the whole `meta-qt5` that has the required python packages in
it already.
Perhaps you'll have more luck with that than porting a recipe.

Be Well,
Alan





On Sat, Mar 10, 2018 at 7:28 PM, Peter Balazovic
 wrote:
> i've added "sip" package to my build and mow by using python-pyqt5_5.8.2.bb
>
>
> ERROR: python-pyqt5-5.8.2-r0 do_patch: Command Error: 'quilt --quiltrc
> /home/ubuntu/work/morty/fsl-release-bsp-imx6/build/tmp/sysroots/x86_64-linux/etc/quiltrc
> push' exited with 0  Output:
> Applying patch fix-sm.patch
> patch:  Only garbage was found in the patch input.
> Patch fix-sm.patch does not apply (enforce with -f)
> ERROR: python-pyqt5-5.8.2-r0 do_patch: Function failed: patch_do_patch
> ERROR: Logfile of failure stored in:
> /home/ubuntu/work/morty/fsl-release-bsp-imx6/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/python-pyqt5/5.8.2-r0/temp/log.do_patch.6327
> ERROR: Task
> (/home/ubuntu/work/morty/fsl-release-bsp-imx6/sources/meta-qt5/recipes-python/pyqt5/python-pyqt5_5.8.2.bb:do_patch)
> failed with exit code '1'
> NOTE: Tasks Summary: Attempted 7479 tasks of which 7474 didn't need to be
> rerun and 1 failed.
>
>
>
>
> On Sat, Mar 10, 2018 at 6:14 PM, Peter Balazovic 
> wrote:
>>
>> I have repo from
>> http://git.freescale.com/git/cgit.cgi/imx/fsl-arm-yocto-bsp.git/ branch
>> imx-morty
>> there is layer "meta-qt5" but does not contain "python-pyqt" or
>> ""python-pyqt5" recipes.
>>
>> I copied python-pyqt5_5.8.2.bb recipe from
>> https://layers.openembedded.org/layerindex/recipe/60914/
>>
>>
>> On Sat, Mar 10, 2018 at 3:41 PM, Alan Martinovic
>>  wrote:
>>>
>>> Seems like the name of the package is: python-pyqt5
>>>
>>> A recipe with that name does exist in meta-qt5:
>>> https://layers.openembedded.org/layerindex/recipe/60914/
>>>
>>> As on why bitbake didn't automatically set the recipe for execution
>>> (based on RDEPENDS) but you would need to manually add it to
>>> IMAGE_INSTALL_append
>>> I don't know.
>>>
>>> Do you have meta-qt5 in your layers?
>>>
>>>
>>> On Sat, Mar 10, 2018 at 1:53 PM, Peter Balazovic
>>>  wrote:
>>> > Dears,
>>> >
>>> >
>>> >
>>> > per Yocto build from fsl-arm-yocto-bsp.git - i.MX Linux BSP Release
>>> > Yocto
>>> > Project manifests of imx-morty branch I have built fsl-image-qt5 image,
>>> > I
>>> > need to add qt5 python support, how to add to the image?
>>> >
>>> >
>>> >
>>> > Modifying local.conf not works
>>> >
>>> > IMAGE_INSTALL_append += "python-pyqt"
>>> >
>>> >
>>> > I end up with errors...
>>> >
>>> >
>>> > ERROR: Nothing RPROVIDES 'python-pyqt5' (but
>>> >
>>> > /home/ubuntu/work/morty/fsl-release-bsp-imx6/sources/meta-fsl-bsp-release/imx/meta-sdk/recipes-fsl/images/fsl-image-qt5.bb
>>> > RDEPENDS on or otherwise requires it)
>>> >
>>> > NOTE: Runtime target 'python-pyqt5' is unbuildable, removing...
>>> >
>>> > Missing or unbuildable dependency chain was: ['python-pyqt5']
>>> >
>>> > ERROR: Required build target 'fsl-image-qt5' has no buildable
>>> > providers.
>>> >
>>> > Missing or unbuildable dependency chain was: ['fsl-image-qt5',
>>> > 'python-pyqt5']
>>> >
>>> >
>>> >
>>> > How to add python QT5 support to Yocto image build?
>>> >
>>> >
>>> > Thank you.
>>> >
>>> > --
>>> > ___
>>> > 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] O_RDONLY ... missed bits/fcntl.h not as expected

2018-03-12 Thread Burton, Ross

Can you explain what the actual problem is?

For me the include you'd use in programs  includes 
which includes  which defines O_RDONLY.

Ross


On 12 March 2018 at 07:32, Arno Steffens  wrote:

> I looked for
> #define O_RDONLY 00
> #define O_WRONLY 01
> #define O_RDWR   02
> and found it in : bits/fcntl-linux.h. According to this file it should not
> be included, but bits/fcntl.h.
> And it requires something like that:
>
>   A minimal  contains just:
>struct flock {...}
>#ifdef __USE_LARGEFILE64
>struct flock64 {...}
>#endif
>#include 
>
>
>
> But this doesn't finally include the fcntl-linux.h as expected. Am I doing
> something wrong?
> Regards
> Arno
>
>
>
> --
> ___
> 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] passwd fails for other users than root

2018-03-12 Thread Maxin B. John

Hi Arno,

On Fri, Mar 09, 2018 at 07:19:06AM +0100, Arno Steffens wrote:
> I have 2 extra users (added with useradd_example.bb). Login works for all 3 
> parties.
> 
> While login works, passwd (to change it) doesn't work for the extra users. 
> They will asked for the old one - which fails.
> Root is not to be asked for old password. That's way root can change password 
> for all. 
> 
> The strange issue is, that after root changes password for users, they can do 
> it by themselves.
> Seems that login and passwd use different algos!?!?
> 
> Same password, but different hashes:
> before (created by yocto)
> user:$6$bk.Az/8KVV$v3TyAlroQeBZA3faJ.DxCVsCUBZaSAvB4FkuNkLDdsIchrmz6OnUGRnQI5BOgOjQ3mvj9QL3US6Amf2VWr0.j/:17598:0:9:7:::
> behind (changed by root):
> user:$1$d3Uo1g82$Il2kYQj8qadzQvkwUU4Ia.:17598:0:9:7:::
> 
> Edit: After a few further test I found that this has an effect:
> I used EXTRA_IMAGE_FEATURES += "read-only-rootfs" to create a read-only-rootf 
> (by default). 
> But of course I did make the partition writeable before attempting to change 
> the password.
> But for some strange reasons this is not same. What might be the reason?

Can you please share the version details and the useradd_example.bb that was 
mentioned here ?
or even better, file a bug in Yocto's bugzilla 
(https://bugzilla.yoctoproject.org) ?

Best Regards,
Maxin
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] O_RDONLY ... missed bits/fcntl.h not as expected

2018-03-12 Thread Arno Steffens

I looked for 
#define O_RDONLY 00
#define O_WRONLY 01
#define O_RDWR   02
and found it in : bits/fcntl-linux.h. According to this file it should not be 
included, but bits/fcntl.h.
And it requires something like that:

  A minimal  contains just: 
   struct flock {...} 
   #ifdef __USE_LARGEFILE64 
   struct flock64 {...} 
   #endif 
   #include  



But this doesn't finally include the fcntl-linux.h as expected. Am I doing 
something wrong?
Regards
Arno



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

[yocto] [ANNOUNCEMENT] Yocto Project 2.4.2 (rocko-18.0.2) Released

Re: [yocto] extending HOSTTOOLS

[yocto] Benchmarking SDHC and SDIO driver

Re: [yocto] Function failed: do_package_qa

[yocto] Fwd: Integrating Ixxat SocketCAN Drivers in image

[yocto] Integrating Ixxat SocketCAN Drivers in image

[yocto] [meta-java][PATCH 2/2] openjdk-8: fix build with --as-needed host toolchains (Ubuntu 16.04)

[yocto] [meta-java][PATCH 1/2] openjdk-8: fix MAKE detection patch

[yocto] IMPORTANT: do_patch() fuzz warnings and how to deal with them

[yocto] Yocto Project Status WW11’18

Re: [yocto] Function failed: do_package_qa

Re: [yocto] Function failed: do_package_qa

Re: [yocto] Function failed: do_package_qa

Re: [yocto] Function failed: do_package_qa

[yocto] Function failed: do_package_qa

Re: [yocto] O_RDONLY ... missed bits/fcntl.h not as expected

Re: [yocto] O_RDONLY ... missed bits/fcntl.h not as expected

Re: [yocto] O_RDONLY ... missed bits/fcntl.h not as expected

Re: [yocto] O_RDONLY ... missed bits/fcntl.h not as expected

Re: [yocto] python-pyqt

Re: [yocto] O_RDONLY ... missed bits/fcntl.h not as expected

Re: [yocto] passwd fails for other users than root

[yocto] O_RDONLY ... missed bits/fcntl.h not as expected

23 matches

Site Navigation

Mail list logo

Footer information