date:20180305

[yocto] Are Windows SDKs (mingw layer) supposed to work?

2018-03-05 Thread Reyna, David

Hi all,

I am trying to enable a customer for using YP SDKs on Windows. It apparently is 
supposed to work, but I am unable to get past fatal errors.

I have looked for documentation at the YP site and the meta-mingw repo, but to 
no avail.

1) My project is a simple default "qemux86-64" with YP-2.5 HEAD, with the 
latest "meta-mingw" layer added and .

The SDK builds fine and I get the "*.xz" generated file.

2) However, when I use 7ZIP to extract it on my Windows host (which is 
recommended for XY files), I get several fatal issues.

  (a) I get more than a hundred errors "Can not create symbolic link: Access is 
denied".

While I do not care about the ones for the bin tools in the sysroot, I do care 
that most of the cross toolchain EXE files are thusly broken, plus many of the 
libraries and header files in the sysroot.

Am I missing a step?

If I in fact extract this file on my Linux host, I can directly see that it is 
full of symlinks! Why are there symlinks in a Windows-specific tarball?

  (b) If I attempt to build a simple C file from the shell in the SDK 
environment, I either get a silent failure (for the 32-bit toolchain) or a 
blatant error as per:

  x86_64-poky-linux-gcc: error: CreateProcess: No such file or directory

I am assuming this error arises from the broken symlinks, specifically all 
those broken files in:

  SDKDIR\sysroots\i686-pokysdk-mingw32\usr\bin\x86_64-poky-linux-gnux32 (all 
zero length):
03/04/2018  08:29 PM 0 x86_64-poky-linux-gnux32-addr2line.exe
03/04/2018  08:29 PM 0 x86_64-poky-linux-gnux32-ar.exe
03/04/2018  08:29 PM 0 x86_64-poky-linux-gnux32-as.exe
03/04/2018  08:29 PM 0 x86_64-poky-linux-gnux32-c++.exe
03/04/2018  08:29 PM 0 x86_64-poky-linux-gnux32-c++filt.exe
03/04/2018  08:29 PM 0 x86_64-poky-linux-gnux32-cpp.exe
03/04/2018  08:29 PM 0 x86_64-poky-linux-gnux32-elfedit.exe
03/04/2018  08:29 PM 0 x86_64-poky-linux-gnux32-g++.exe
03/04/2018  08:29 PM 0 x86_64-poky-linux-gnux32-gcc-ar.exe
...

  
SDKDIR\sysroots\i686-pokysdk-mingw32\usr\libexec\x86_64-poky-linux\gcc\x86_64-poky-linux\7.3.0\*
03/04/2018  08:29 PM 0 ar.exe
03/04/2018  08:29 PM 0 as.exe
02/23/2018  03:48 PM21,962,568 cc1.exe
02/23/2018  03:48 PM23,256,499 cc1plus.exe
02/23/2018  03:48 PM   812,905 collect2.exe
03/04/2018  08:29 PM 0 cpp.exe
03/04/2018  08:29 PM 0 gcc.exe
03/04/2018  08:29 PM 0 ld.exe
02/23/2018  03:48 PM 1,101,508 lto-wrapper.exe
03/04/2018  08:29 PM 0 nm.exe
03/04/2018  08:29 PM 0 objcopy.exe
03/04/2018  08:29 PM 0 objdump.exe
03/04/2018  08:29 PM 0 ranlib.exe
03/04/2018  08:29 PM 0 real-ld.exe
03/04/2018  08:29 PM 0 strip.exe

3) I have done '-v' and ProcessMonitor tracing, and it all seems to come down 
to these broken links.

4) I see that Yang Wang had the same question (below), and I have not seen an 
answer.

Please help,
David Reyna


From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Wang, Yang Y
Sent: Thursday, August 17, 2017 11:41 PM
To: Yocto
Subject: [yocto] toolchain from meta-mingw gets error x86_64-poky-linux-gcc: 
error: CreateProcess: No such file or directory

I'm using Yocto krogoth and meta-mingw to build the meta-toolchain for windows 
system. The build is quite smooth.
I extract the built toolchain 
poky-glibc-x86_64-meta-toolchain-core2-64-toolchain-2.1.tar.xz on windows to 
c:/yocto2.1
However when I try to run a simple build from windows cmd console after I set 
up the environment-setup-core2-64-poky-linux.bat, I got the following error.
By further check, it seems the error is related to the symbolic link in folder 
sysroots/x86_64-pokysdk-mingw32/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/5.3.0/
 where the as, ar etc binutiles are the symbolic link to the file in -> 
../../../../../bin/x86_64-poky-linux/
However on windows, such "../../" symbolic link can't work. Simply execute the 
symbolic 'as.exe' will get error "Access is denied."

Anyone has the idea on how to solve this issue?

c:\Yocto2.1>%CC% c:/temp/temp/temp/test.c
x86_64-poky-linux-gcc: error: CreateProcess: No such file or directory

c:\Yocto2.1>%CC% c:/temp/temp/temp/test.c --verbose
Using built-in specs.
COLLECT_GCC=x86_64-poky-linux-gcc
COLLECT_LTO_WRAPPER=c:/yocto2.1/sysroots/x86_64-pokysdk-mingw32/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/5.3.0/lto-wrapper.exe
Target: x86_64-poky-linux

GNU C11 (GCC) version 5.3.0 (x86_64-poky-linux)
compiled by GNU C version 5.3.0, GMP version 6.1.0, MPFR version 3.1.3, 
MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable c

Re: [yocto] [meta-java][PATCH 00/14] openjdk-8 updates

2018-03-05 Thread Khem Raj

On Mon, Mar 5, 2018 at 1:30 AM, André Draszik  wrote:
> Hi,
>
> OpenJDK8 in yocto is a bit outdated, so these patches
> - update openjdk-8 from the 1.5 year old version 102b14 to the
>   current 162b12
> - modernize the recipe using bitbake variable overrides
> - enable building with 'security' flags enabled
> - fix the aarch64 build (by using the aarch64 port, which is
>   still separate in the OpenJDK8 series)
> - fix the musl build (by adding appropriate patches)
>
> This was runtime-tested on x86-64 with both glibc and musl
> against the 'poky' DISTRO, and compile-tested on aarch64
> against glibc and musl.
>


this series looks good thanks for fixing musl port

> Cheers,
> Andre'
>
> --
> ___
> 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-intel] [PATCH] systemd-boot: fix bbappend file to suit latest version

2018-03-05 Thread ChenQi


On 03/06/2018 05:51 AM, Cal Sullivan wrote:
Thanks for the patch. I assume this is needed when OE-core merges the 
update to v236?


Thanks,
Cal



Yes. It's needed when OE-core merges the update to v237.

Best Regards,
Chen Qi


On 03/04/2018 06:03 PM, Chen Qi wrote:

Fix the bbappend file to suit the latest systemd version.

As systemd has now dropped autotools support, using ninja
instead of make in do_compile.

Signed-off-by: Chen Qi 
---
  recipes-bsp/systemd-boot/systemd-boot_%.bbappend | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/recipes-bsp/systemd-boot/systemd-boot_%.bbappend 
b/recipes-bsp/systemd-boot/systemd-boot_%.bbappend

index 9e6cc16..46dd8a4 100644
--- a/recipes-bsp/systemd-boot/systemd-boot_%.bbappend
+++ b/recipes-bsp/systemd-boot/systemd-boot_%.bbappend
@@ -7,11 +7,11 @@ SRC_URI_append_intel-x86-common = " \
  PACKAGE_ARCH_intel-x86-common = "${INTEL_COMMON_PACKAGE_ARCH}"
do_compile_append_intel-x86-common() {
-oe_runmake linux${SYSTEMD_BOOT_EFI_ARCH}.efi.stub
+ninja src/boot/efi/linux${SYSTEMD_BOOT_EFI_ARCH}.efi.stub
  }
do_deploy_append_intel-x86-common() {
-install ${B}/linux*.efi.stub ${DEPLOYDIR}
+install ${B}/src/boot/efi/linux*.efi.stub ${DEPLOYDIR}
  }
# includes rmc-boot.inc if rmc-boot is the EFI_PROVIDER





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

Re: [yocto] Adding custom scripts to home directory and /etc/init.d/*

2018-03-05 Thread Anuj Mittal

On 03/06/2018 05:18 AM, Giordon Stark wrote:
> Hi all,
> 
> I am wondering if there's a nice pattern or workflow within Yocto where
> I can add a custom shell script to /etc/init.d for the purposes of
> running it on OS boot (which also requires running update.rc I believe)

You can inherit update-rc.d class and define INITSCRIPT_NAME/PARAMS in
your recipe.

https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#ref-classes-update-rc.d

> as well as prepopulating the home directory with some files of my choosing.
> 
> If someone could point me in the right direction, that would be great!
> 
> Giordon
> -- 
> Giordon Stark
> 
> 

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

Re: [yocto] [meta-intel] [PATCH] systemd-boot: fix bbappend file to suit latest version

2018-03-05 Thread Cal Sullivan

Thanks for the patch. I assume this is needed when OE-core merges the 
update to v236?


Thanks,
Cal

On 03/04/2018 06:03 PM, Chen Qi wrote:

Fix the bbappend file to suit the latest systemd version.

As systemd has now dropped autotools support, using ninja
instead of make in do_compile.

Signed-off-by: Chen Qi 
---
  recipes-bsp/systemd-boot/systemd-boot_%.bbappend | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/recipes-bsp/systemd-boot/systemd-boot_%.bbappend 
b/recipes-bsp/systemd-boot/systemd-boot_%.bbappend
index 9e6cc16..46dd8a4 100644
--- a/recipes-bsp/systemd-boot/systemd-boot_%.bbappend
+++ b/recipes-bsp/systemd-boot/systemd-boot_%.bbappend
@@ -7,11 +7,11 @@ SRC_URI_append_intel-x86-common = " \
  PACKAGE_ARCH_intel-x86-common = "${INTEL_COMMON_PACKAGE_ARCH}"
  
  do_compile_append_intel-x86-common() {

-   oe_runmake linux${SYSTEMD_BOOT_EFI_ARCH}.efi.stub
+   ninja src/boot/efi/linux${SYSTEMD_BOOT_EFI_ARCH}.efi.stub
  }
  
  do_deploy_append_intel-x86-common() {

-   install ${B}/linux*.efi.stub ${DEPLOYDIR}
+   install ${B}/src/boot/efi/linux*.efi.stub ${DEPLOYDIR}
  }
  
  # includes rmc-boot.inc if rmc-boot is the EFI_PROVIDER


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

[yocto] Adding custom scripts to home directory and /etc/init.d/*

2018-03-05 Thread Giordon Stark

Hi all,

I am wondering if there's a nice pattern or workflow within Yocto where I
can add a custom shell script to /etc/init.d for the purposes of running it
on OS boot (which also requires running update.rc I believe) as well as
prepopulating the home directory with some files of my choosing.

If someone could point me in the right direction, that would be great!

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

[yocto] Strange filesystem problem using docker on a pyro based system

2018-03-05 Thread Peter Spierenburg

I am building docker on a pyro based system. I'm using the overlay storage 
driver, and I am getting a strange result:


When I add a file to a container, any files in the same directory that come 
from the base image disappear... Here is a short script that highlights what I 
mean:


docker build -t test - <<"EOF" FROM debian RUN ls -laF /usr RUN ls -laF 
./usr/bin RUN touch /usr/bin/bogus RUN ls -laF /usr RUN ls -laF ./usr/bin EOF 
docker run -it --name=test_container test sh -c "ls -laF /usr ; ls -laF 
./usr/bin ; whoami && echo PASS || echo FAIL" docker logs test_container docker 
rm test_container docker rmi test


When I run the script above, creating the /usr/bin/bogus file causes all other 
files in /usr/bin to disappear, so that when the script tries to run the whoami 
command it fails with


sh: 1: whoami: not found


I figure that I have missed some important kernel config option. According to 
/usr/share/docker/contrib/check-config.sh:


info: reading kernel config from /proc/config.gz ...

Generally Necessary:
- cgroup hierarchy: properly mounted [/sys/fs/cgroup]
- CONFIG_NAMESPACES: enabled
- CONFIG_NET_NS: enabled
- CONFIG_PID_NS: enabled
- CONFIG_IPC_NS: enabled
- CONFIG_UTS_NS: enabled
- CONFIG_CGROUPS: enabled
- CONFIG_CGROUP_CPUACCT: enabled
- CONFIG_CGROUP_DEVICE: enabled
- CONFIG_CGROUP_FREEZER: enabled
- CONFIG_CGROUP_SCHED: enabled
- CONFIG_CPUSETS: enabled
- CONFIG_MEMCG: enabled
- CONFIG_KEYS: enabled
- CONFIG_VETH: enabled
- CONFIG_BRIDGE: enabled (as module)
- CONFIG_BRIDGE_NETFILTER: enabled (as module)
- CONFIG_NF_NAT_IPV4: enabled (as module)
- CONFIG_IP_NF_FILTER: enabled (as module)
- CONFIG_IP_NF_TARGET_MASQUERADE: enabled (as module)
- CONFIG_NETFILTER_XT_MATCH_ADDRTYPE: enabled (as module)
- CONFIG_NETFILTER_XT_MATCH_CONNTRACK: enabled (as module)
- CONFIG_NETFILTER_XT_MATCH_IPVS: enabled (as module)
- CONFIG_IP_NF_NAT: enabled (as module)
- CONFIG_NF_NAT: enabled (as module)
- CONFIG_NF_NAT_NEEDED: enabled
- CONFIG_POSIX_MQUEUE: enabled
- CONFIG_DEVPTS_MULTIPLE_INSTANCES: enabled

Optional Features:
- CONFIG_USER_NS: enabled
- CONFIG_SECCOMP: enabled
- CONFIG_CGROUP_PIDS: missing
- CONFIG_MEMCG_SWAP: missing
- CONFIG_MEMCG_SWAP_ENABLED: missing
- CONFIG_MEMCG_KMEM: enabled
- CONFIG_BLK_CGROUP: missing
- CONFIG_BLK_DEV_THROTTLING: missing
- CONFIG_IOSCHED_CFQ: enabled (as module)
- CONFIG_CFQ_GROUP_IOSCHED: missing
- CONFIG_CGROUP_PERF: enabled
- CONFIG_CGROUP_HUGETLB: missing
- CONFIG_NET_CLS_CGROUP: enabled (as module)
- CONFIG_CGROUP_NET_PRIO: enabled
- CONFIG_CFS_BANDWIDTH: enabled
- CONFIG_FAIR_GROUP_SCHED: enabled
- CONFIG_RT_GROUP_SCHED: enabled
- CONFIG_IP_VS: enabled (as module)
- CONFIG_IP_VS_NFCT: enabled
- CONFIG_IP_VS_RR: enabled (as module)
- CONFIG_EXT3_FS: missing
- CONFIG_EXT3_FS_XATTR: missing
- CONFIG_EXT3_FS_POSIX_ACL: missing
- CONFIG_EXT3_FS_SECURITY: missing
(enable these ext3 configs if you are using ext3 as backing filesystem)
- CONFIG_EXT4_FS: enabled
- CONFIG_EXT4_FS_POSIX_ACL: enabled
- CONFIG_EXT4_FS_SECURITY: enabled
- Network Drivers:
  - "overlay":
- CONFIG_VXLAN: missing
  Optional (for encrypted networks):
  - CONFIG_CRYPTO: enabled
  - CONFIG_CRYPTO_AEAD: missing
  - CONFIG_CRYPTO_GCM: missing
  - CONFIG_CRYPTO_SEQIV: missing
  - CONFIG_CRYPTO_GHASH: missing
  - CONFIG_XFRM: enabled
  - CONFIG_XFRM_USER: enabled (as module)
  - CONFIG_XFRM_ALGO: enabled (as module)
  - CONFIG_INET_ESP: missing
  - CONFIG_INET_XFRM_MODE_TRANSPORT: enabled
  - "ipvlan":
- CONFIG_IPVLAN: missing
  - "macvlan":
- CONFIG_MACVLAN: enabled
- CONFIG_DUMMY: missing
  - "ftp,tftp client in container":
- CONFIG_NF_NAT_FTP: enabled (as module)
- CONFIG_NF_CONNTRACK_FTP: enabled (as module)
- CONFIG_NF_NAT_TFTP: enabled (as module)
- CONFIG_NF_CONNTRACK_TFTP: enabled (as module)
- Storage Drivers:
  - "aufs":
- CONFIG_AUFS_FS: missing
  - "btrfs":
- CONFIG_BTRFS_FS: missing
- CONFIG_BTRFS_FS_POSIX_ACL: missing
  - "devicemapper":
- CONFIG_BLK_DEV_DM: missing
- CONFIG_DM_THIN_PROVISIONING: missing
  - "overlay":
- CONFIG_OVERLAY_FS: enabled (as module)
  - "zfs":
- /dev/zfs: missing
- zfs command: missing
- zpool command: missing

Limits:
- /proc/sys/kernel/keys/root_maxkeys: 100


This communication, including any attached documentation, is intended only for 
the person or entity to which it is addressed, and may contain confidential, 
personal, and/or privileged information. Any unauthorized disclosure, copying, 
or taking action on the contents is strictly prohibited. If you have received 
this message in error, please contact us immediately so we may correct our 
records. Please then delete or destroy the original transmission and any 
subsequent reply. Thank you.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] Subject: Yocto Project Status WW10’18

2018-03-05 Thread Burton, Ross

On 5 March 2018 at 16:30, akuster808  wrote:

>
>- Performance metrics indicate that a recent merge has caused a
>slowdown in build times.
>
> Is this data publicly available?
>

https://lists.yoctoproject.org/pipermail/yocto-perf/2018-March/thread.html

The HTML mails are much more readable...

The raw data is in the wiki somewhere but I can't recall where right now.


>
>- Flood of last-minute upgrades continuing to be reviewed and merged
>if low-impact.
>
>
> Is there a cut off on package upgrades?
>

Strictly speaking,  weeks ago.  If an upgrade appears safe it might well
sneak in now.

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

Re: [yocto] Subject: Yocto Project Status WW10’18

2018-03-05 Thread akuster808



On 03/05/2018 08:03 AM, Jordan, Robin L wrote:
>
> Subject: Yocto Project Status WW10’18
>
>  
>
> 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 team rotation: Rebecca -> Cal on March 9, 2018
>
> SWAT team rotation: Cal -> Armin on March 16, 2018
>
> https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team
>
>  
>
> Key Status/Updates:
>
>   * YP 2.5 M2 was released February 27.
>   o This milestone release includes CVE fixes and 60 recipe
> upgrades*. * It incorporates security fixes**with upgrades to
> gcc and kernels to all current stable versions.  Headline
> changes include reproducibility improvements, gettext build
> performance, image generation, and cmake using Ninja by
> default.  This release added gobject-introspection tests to
> testimage, integrated support for the Meson build system,
> Python build/packaging refactoring, and redesigned postinstall
> script handling.
>   * YP 2.2.3 was released February 27.
>   o A total of**97 CVE fixes** and other fixes to work with GCC 7
> on newer host OSs.
>   o We have committed to a 2.2.4 release to integrate all
> remaining security fixes.
>   * YP 2.4.2 RC2 came out of QA today (report at
> 
> https://wiki.yoctoproject.org/wiki/WW10_-_2018-03-05-_Full_Test_Cycle_-_2.4.2_rc2)
>
>   * YP 2.5 M3 is in final feature freeze. Reviewing last week’s
> required features:
>   o 2.27 glibc upgrade has been merged. This meant making SDK
> changes so they’re all ~50M larger now thanks to the need to
> ship locales. However the same underlying code could be reused
> to generate locale archives in images, which will make those
> smaller.
>   o kernel-devsrc size reduction: the blocking issue has been
> resolved so waiting for an updated patch.
>   o pseudo upgrade has been merged which should solve many issues,
> and Peter is investigating the long-standing host
> contamination issue.
>   o Still need to resolve the multilib SDK patch series.
>   o Package feed filtering has been merged.
>   o Image EFI configuration rework under review now.
>   * Performance metrics indicate that a recent merge has caused a
> slowdown in build times.
>
Is this data publicly available?

>   *  It is suspected that the glibc upgrade is the cause of this
> although help would be appreciated to verify this.
>   * Flood of last-minute upgrades continuing to be reviewed and merged
> if low-impact.
>

Is there a cut off on package upgrades?

>  *
>   * Go upgrade/improvements are under review, possibly we’ll ship both
> Go 1.9.4 and 1.10 in 2.5 but do plan to drop 1.9.4 from master as
> soon as 1.10 doesn’t present compatibility problems.
>   * We’re 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’d 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 we figure out gcc backports.
>

yocto-linux 4.10 still needs updating.

> YP 2.2.4 (Morty) will be built when we figure out gcc backports.
>
kernel 4.8 has a pull request
kernel 4.1 pull request sent that includes  spectre changes and some
general fixes.

- armin

> 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 2663 (last week 2646)
>
> (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!]
>
>  
>
>
>

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

Re: [yocto] RREPLACE is not applied do_package_qa() ?

2018-03-05 Thread Burton, Ross

That isn't what replaces is for: RREPLACES is used to hint to the package
manager what package should be removed when there are conflicts.  It won't
have any impact on package dependencies at any other time.

Ross

On 1 March 2018 at 03:29, ikjn  wrote:

> Hi.
>
> I'm building mali userspace libraries using meta-mali layer + rocko
> but I got errors like these:
>
> ERROR: cogl-1.0-1.22.2-r0 do_package_qa: QA Issue:
> /usr/lib/libcogl-pango.so.20.4.2 contained in package libcogl-pango
> requires libwayland-egl.so, but no providers found in
> RDEPENDS_libcogl-pango? [file-rdeps]
>
> Current recipes are:
>
> * mesa.bb
> PACKAGES = "... libwayland-egl"
> FILES_libwayland_egl = "libwaland-egl.so"
>
> * mali.bb
> do_install() { copy libmali.so to libdir; create a soft
> link(libwayland-egl.so --> libmali.so) }
> PACKAGES = "mali"
> FILES_mali = "${libdir}/*.so"
> RREPLACE_mali = "... libwayland-egl"
>
> * cogl.bb
> RDEPENDS_libcogl-pango = "libwayland-egl"
>
> In this structure, mali specify RREPLACE = libwayland-egl, so I guessed
> package 'libwayland-egl' dependency is replaced by package 'mali' like this:
>
> cogl RDEPENDS--> libwayland-egl
>   ~~> mesa RPROVIDES libwayland-egl
>   ~~> RREPLACE_mali libwayland-egl
>
> But with bitbake -v -c build cogl-1.0 shows that libwayland-egl package
> provides no FILERPROVIDES_xxx on here.
>
> Am I wrong about RREPLACE chain?
> or the problem comes from something else?
> I'm a newbie on yocto and very confused, please help me!
>
> Thanks.
>
>
> --
> ___
> 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] Yocto plugin java null pointer exception issue.

2018-03-05 Thread Rahul Dhobi


Hello,

We are currently building windows SDK using Yocto 2.4. So far we are 
able to generate SDK for windows but getting "java null pointer 
exception". We found there was bug 
 raised for same 
issue but, we are still facing same issue in org.yocto.sdk - 
1.4.1.201710162310 
 
plugin. Please help us to use sdk in eclipse with Yocto adt plugin.


--


 Regards,
 Rahul R Dhobi,
 System Level Solutions (I) Pvt. Ltd.

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

Re: [yocto] [dev] [meta-oic] Question about Iotivity 1.3.0/1 and fixes status

2018-03-05 Thread Philippe Coval

On Fri, Jan 12, 2018 at 3:26 AM, Chanho Park  wrote:

> Hi Philippe,
>
> On Thu, 11 Jan 2018 at 7:11 PM Philippe Coval  com> wrote:
>
>>
>> On 11/01/18 02:30, Chanho Park wrote:
>> > Hi Philippe,
>> >
>
>

> Okay. I’ll test them when you resend them. Please CCing me at that time.
>>
>
>
1.3.0 is now merged in:

http://git.yoctoproject.org/cgit/cgit.cgi/meta-oic/commit/README?id=eb7dfc4764ce538fc84eb40f1ca7ed7e14eb1f1d

I will commit more pending patches in coming days/week,
feedback is always welcome in iotivity tracker (add yocto label)



> Okay. I look forward to your results :)
> Thanks.
>
>
Thank you for your patience, now It should me faster since I got commit
rights.

Regards

-- 
gpg:0x467094BC
xmpp:philippe.coval@gmail.com
https://wiki.tizen.org/wiki/User:Pcoval
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] RREPLACE is not applied do_package_qa() ?

2018-03-05 Thread ikjn

Hi.

I'm building mali userspace libraries using meta-mali layer + rocko
but I got errors like these:

ERROR: cogl-1.0-1.22.2-r0 do_package_qa: QA Issue:
/usr/lib/libcogl-pango.so.20.4.2 contained in package libcogl-pango
requires libwayland-egl.so, but no providers found in
RDEPENDS_libcogl-pango? [file-rdeps]

Current recipes are:

* mesa.bb
PACKAGES = "... libwayland-egl"
FILES_libwayland_egl = "libwaland-egl.so"

* mali.bb
do_install() { copy libmali.so to libdir; create a soft
link(libwayland-egl.so --> libmali.so) }
PACKAGES = "mali"
FILES_mali = "${libdir}/*.so"
RREPLACE_mali = "... libwayland-egl"

* cogl.bb
RDEPENDS_libcogl-pango = "libwayland-egl"

In this structure, mali specify RREPLACE = libwayland-egl, so I guessed
package 'libwayland-egl' dependency is replaced by package 'mali' like this:

cogl RDEPENDS--> libwayland-egl
  ~~> mesa RPROVIDES libwayland-egl
  ~~> RREPLACE_mali libwayland-egl

But with bitbake -v -c build cogl-1.0 shows that libwayland-egl package
provides no FILERPROVIDES_xxx on here.

Am I wrong about RREPLACE chain?
or the problem comes from something else?
I'm a newbie on yocto and very confused, please help me!

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

[yocto] Unable to generate licenses

2018-03-05 Thread Johnston, Rick

I'm using bitbake version 1.28 and trying to get the license manifest for my 
project.  I've made the changes described in "Maintaining Open Source License 
Compliance During Your Product's Lifecycle" of the Mega-Manual and also tried 
adding "inherit license" to my recipe, but while I do get the license 
directories generated, there's never any data.  I also tried "-c populate_lic" 
to no avail.

Is there another trick necessary to get this output?

RICK JOHNSTON
Staff SW Engineer
ARRIS

o: +1 978-614-2404
e: rick.johns...@arris.com
w: www.arrisi.com

Follow our blog: www.arriseverywhere.com

This electronic transmission (and any attached document) is for the sole use of 
the individual or entity to whom it is addressed.  It is confidential and may 
be attorney-client privileged.  In any event the Sender reserves, to the 
fullest extent, any "legal advice privilege".  Any further distribution or 
copying of this message is strictly prohibited.  If you received this message 
in error, please notify the Sender immediately and destroy the attached message 
(and all attached documents).

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

[yocto] Subject: Yocto Project Status WW10’18

2018-03-05 Thread Jordan, Robin L

Subject: Yocto Project Status WW10’18

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 team rotation: Rebecca -> Cal on March 9, 2018
SWAT team rotation: Cal -> Armin on March 16, 2018
https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team

Key Status/Updates:

  *   YP 2.5 M2 was released February 27.
 *   This milestone release includes CVE fixes and 60 recipe upgrades.  It 
incorporates security fixes with upgrades to gcc and kernels to all current 
stable versions.  Headline changes include reproducibility improvements, 
gettext build performance, image generation, and cmake using Ninja by default.  
This release added gobject-introspection tests to testimage, integrated support 
for the Meson build system, Python build/packaging refactoring, and redesigned 
postinstall script handling.
  *   YP 2.2.3 was released February 27.
 *   A total of 97 CVE fixes and other fixes to work with GCC 7 on newer 
host OSs.
 *   We have committed to a 2.2.4 release to integrate all remaining 
security fixes.
  *   YP 2.4.2 RC2 came out of QA today (report at 
https://wiki.yoctoproject.org/wiki/WW10_-_2018-03-05-_Full_Test_Cycle_-_2.4.2_rc2)

  *   YP 2.5 M3 is in final feature freeze. Reviewing last week’s required 
features:
 *   2.27 glibc upgrade has been merged. This meant making SDK changes so 
they’re all ~50M larger now thanks to the need to ship locales. However the 
same underlying code could be reused to generate locale archives in images, 
which will make those smaller.
 *   kernel-devsrc size reduction: the blocking issue has been resolved so 
waiting for an updated patch.
 *   pseudo upgrade has been merged which should solve many issues, and 
Peter is investigating the long-standing host contamination issue.
 *   Still need to resolve the multilib SDK patch series.
 *   Package feed filtering has been merged.
 *   Image EFI configuration rework under review now.
  *   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 this.
  *   Flood of last-minute upgrades continuing to be reviewed and merged if 
low-impact.
  *   Go upgrade/improvements are under review, possibly we’ll ship both Go 
1.9.4 and 1.10 in 2.5 but do plan to drop 1.9.4 from master as soon as 1.10 
doesn’t present compatibility problems.
  *   We’re 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’d 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 we figure out gcc backports.
YP 2.2.4 (Morty) will be built when we figure out gcc backports.
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 2663 (last week 2646)
(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!]

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

Re: [yocto] Connecting AutoBuilder output to GitLab for meta-mono CI

2018-03-05 Thread Alex Lennon




On 05/03/2018 10:35, Paul Barker wrote:

On Mon, Mar 5, 2018 at 9:52 AM, Alex Lennon
 wrote:

Hi all,

I've been running an autobuilder locally for a while now to automate testing
of meta-mono commits.

I see recently saw GitLab seems to support CI workers publishing logs and
artifacts to the site and this seems a useful thing to me.

Does anybody have any pointers on where to go look for details on how to set
this up, or can offer advice to me as I set it up?

Thanks,

Alex


The logs are just the stdio/stderr output of the job so to have those
display properly you'd either need to do everything in GitLab CI or
have some sort of hack where the GitLab CI job reads the build log
from your autobuilder and writes it to stdout.

Build artifacts are a bit easier, you could define a GitLab CI job
that copies the artifacts from your current autobuilder.

You could instead move over to GitLab CI fully but I do find it a bit
limited at times - there's no high level summary across multiple
projects so you can't see how often your workers are busy, how many
builds are queued, etc. I find that ok for a small team but once
you've got more than 4 or 5 people working together you'll probably
need those stats to know how to scale your infrastructure.

Thanks,



Thanks for that Paul - really useful feedback.

Cheers!

Alex

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

Re: [yocto] bitbake: git and patch problem

2018-03-05 Thread EXTERNAL van Riel Rob (ENTER, BT-CO/ENG1.1)

> -Original Message-
> From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
> Sent: maandag 5 maart 2018 15:09
> Subject: Re: [yocto] bitbake: git and patch problem
> 
> Out of curiosity .. why is that unexpected, or inconvenient ? I never want a 
> git
> repository to have dirty/unchecked in files, so having the build system apply 
> a
> patch, make sure it is a valid format, signed-off-by and then committed is a 
> good
> thing.

Acually, I wouldn't even want to have the patch in my recipes, and simply 
commit the code myself, for pretty much the reasons you mention. However, this 
particular piece of source code is shared between several products, not all of 
which need the change. Permanently and universally making the relevant change 
is out, so patch it is (unless I can come up with a better way to force a 
single define into the build process; I tried adding to CFLAGS, but that wasn't 
picked up. Others have tangled with this for less trivial changes too).
Added to that is that the yocto system is our de facto development environment, 
that is, development is typically done on whatever ends up in the tmp/work 
directories, and pushed to the various version control systems from there. I 
don't really believe this is the correct way to use yocto, but it's what I have 
to deal with.
Current behaviour is unexpected, because I would not expect yocto to be the 
medium for pushing changes back upstream. It is inconvenient, because those git 
clones are what we use to make changes in, some of which are for the global 
code base, and in that situation, I would not want to have to roll back an 
automatic, local change first before getting to work on the global part.

> > Is this expected behaviour, and if so, is there any way to prevent it?
> 
> It is, but you can change what applies the patch.
> 
> Have a look at classes/patch.bbclass, and in particular the variable 
> PATCHTOOL.
> 
> If yours is set to 'git', git will be used. But by default, it is typically 
> set to 'quilt' ..
> so it has been changed from the default in your environment.

Thank you, this may well be just the hint I was looking for. I'll dig in, and 
see where the trail leads.

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

Re: [yocto] bitbake: git and patch problem

2018-03-05 Thread Bruce Ashfield


On 2018-03-05 5:33 AM, EXTERNAL van Riel Rob (ENTER, BT-CO/ENG1.1) wrote:

I'm experiencing strange (at least to my eyes) behaviour from bitbake. My 
recipe specifies a git repository as the main SRC_URI, then, in a variant 
created using an append file adds a patch like this:

SRC_URI_append_mystuff += "file://mystuff.patch"

As expected, this grabs the sources from the git repository, and then applies 
the patch. Rather unexpectedly to me, and also rather inconveniently, it then 
adds and commits the changes to the local git clone.


Out of curiosity .. why is that unexpected, or inconvenient ? I never
want a git repository to have dirty/unchecked in files, so having the
build system apply a patch, make sure it is a valid format, signed-off-by
and then committed is a good thing.



Is this expected behaviour, and if so, is there any way to prevent it?


It is, but you can change what applies the patch.

Have a look at classes/patch.bbclass, and in particular the variable
PATCHTOOL.

If yours is set to 'git', git will be used. But by default, it is
typically set to 'quilt' .. so it has been changed from the default
in your environment.

Bruce



My environment is based on poky-fido-13.0.1.

Best regards,

Rob van Riel



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

Re: [yocto] bitbake: git and patch problem

2018-03-05 Thread EXTERNAL van Riel Rob (ENTER, BT-CO/ENG1.1)

> From: Robert P. J. Day [mailto:rpj...@crashcourse.ca]
> Sent: maandag 5 maart 2018 12:13
> Subject: Re: [yocto] bitbake: git and patch problem
> 
> On Mon, 5 Mar 2018, EXTERNAL van Riel Rob (ENTER, BT-CO/ENG1.1) wrote:
> 
> > I'm experiencing strange (at least to my eyes) behaviour from bitbake.
> > My recipe specifies a git repository as the main SRC_URI, then, in a
> > variant created using an append file adds a patch like
> > this:
> >
> > SRC_URI_append_mystuff += "file://mystuff.patch"
> 
>   pretty sure you don't need both "_append" and "+=" in the same assignment.

Agreed, but you know how it goes: you get handed a system with a long history, 
you need to expand it, so you follow whatever conventions are in place unless 
they bite you.
I ran a test with the patch lumped directly into SRC_URI, and the result was 
identical with this:
SRC_URI += "file://mystuff.patch"

Rob

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

Re: [yocto] bitbake: git and patch problem

2018-03-05 Thread Robert P. J. Day

On Mon, 5 Mar 2018, EXTERNAL van Riel Rob (ENTER, BT-CO/ENG1.1) wrote:

> I'm experiencing strange (at least to my eyes) behaviour from
> bitbake. My recipe specifies a git repository as the main SRC_URI,
> then, in a variant created using an append file adds a patch like
> this:
>
> SRC_URI_append_mystuff += "file://mystuff.patch"

  pretty sure you don't need both "_append" and "+=" in the same
assignment.

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

[yocto] bitbake: git and patch problem

2018-03-05 Thread EXTERNAL van Riel Rob (ENTER, BT-CO/ENG1.1)

I'm experiencing strange (at least to my eyes) behaviour from bitbake. My 
recipe specifies a git repository as the main SRC_URI, then, in a variant 
created using an append file adds a patch like this:

SRC_URI_append_mystuff += "file://mystuff.patch"

As expected, this grabs the sources from the git repository, and then applies 
the patch. Rather unexpectedly to me, and also rather inconveniently, it then 
adds and commits the changes to the local git clone.

Is this expected behaviour, and if so, is there any way to prevent it?

My environment is based on poky-fido-13.0.1.

Best regards,

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

Re: [yocto] Connecting AutoBuilder output to GitLab for meta-mono CI

2018-03-05 Thread Paul Barker

On Mon, Mar 5, 2018 at 9:52 AM, Alex Lennon
 wrote:
> Hi all,
>
> I've been running an autobuilder locally for a while now to automate testing
> of meta-mono commits.
>
> I see recently saw GitLab seems to support CI workers publishing logs and
> artifacts to the site and this seems a useful thing to me.
>
> Does anybody have any pointers on where to go look for details on how to set
> this up, or can offer advice to me as I set it up?
>
> Thanks,
>
> Alex
>

The logs are just the stdio/stderr output of the job so to have those
display properly you'd either need to do everything in GitLab CI or
have some sort of hack where the GitLab CI job reads the build log
from your autobuilder and writes it to stdout.

Build artifacts are a bit easier, you could define a GitLab CI job
that copies the artifacts from your current autobuilder.

You could instead move over to GitLab CI fully but I do find it a bit
limited at times - there's no high level summary across multiple
projects so you can't see how often your workers are busy, how many
builds are queued, etc. I find that ok for a small team but once
you've got more than 4 or 5 people working together you'll probably
need those stats to know how to scale your infrastructure.

Thanks,

-- 
Paul Barker
Togán Labs Ltd
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] QA cycle report for 2.4.2 RC2

2018-03-05 Thread Yeoh, Ee Peng

Hello All,
This is the full report for 2.4.2 RC2:  
https://wiki.yoctoproject.org/wiki/WW10_-_2018-03-05-_Full_Test_Cycle_-_2.4.2_rc2

=== Summary 

The QA cycle for release 2.4.2 RC2 was completed including the performance 
test.  Team had not discovered any new bug.

Performance tests were executed for both 2.4.2 RC2 and 2.4.1 RC1 (as regression 
and benchmark) on these new machines in linux foundation. 

=== QA-Hints

QA shows no new bug, this release is stable for release. 

=== Bugs 

N/A

 Links =
N/A

Regards
Ee Peng 


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

[yocto] Connecting AutoBuilder output to GitLab for meta-mono CI

2018-03-05 Thread Alex Lennon


Hi all,

I've been running an autobuilder locally for a while now to automate 
testing of meta-mono commits.


I see recently saw GitLab seems to support CI workers publishing logs 
and artifacts to the site and this seems a useful thing to me.


Does anybody have any pointers on where to go look for details on how to 
set this up, or can offer advice to me as I set it up?


Thanks,

Alex

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

[yocto] [meta-java][PATCH 13/14] openjdk-8: fix musl build

2018-03-05 Thread André Draszik

From: André Draszik 

Add various patches to make it work in musl. Some of them are generic
enough to be applied for all builds, some need to be specific to musl.

Signed-off-by: André Draszik 
---
 recipes-core/openjdk/openjdk-8-release-162b12.inc  |  16 ++
 ...dk-comparison-between-pointer-and-integer.patch |   2 +-
 ...x-compilation-with-security-flags-enabled.patch |   2 +-
 ...dk-Allow-using-a-system-installed-libjpeg.patch |   2 +-
 ...jdk-Allow-using-a-system-installed-libpng.patch |   2 +-
 ...0005-hotspot-use-correct-include-for-poll.patch |  85 ++
 ...006-hotspot-don-t-rely-on-old-SysV-SIGCLD.patch |  41 +
 .../0007-jdk-use-correct-include-for-poll.patch| 172 +
 .../0008-jdk-use-correct-include-for-signal.patch  |  89 +++
 ...0009-jdk-disable-backtrace-musl-build-fix.patch |  45 ++
 ...l-0001-hotspot-stop-using-obsolete-isnanf.patch |  42 +
 ...-give-a-much-bigger-buffer-to-getmntent_r.patch | 103 
 ...x-libjvm-load-on-musl-set-LD_LIBRARY_PATH.patch |  37 +
 ...dk-remove-sysctl.h-include-musl-build-fix.patch |  90 +++
 .../musl-0005-hotspot-disable-agent-build.patch|  88 +++
 ...otspot-os_linux-remove-glibc-dependencies.patch |  75 +
 ...linux_x86-remove-glibc-dependencies-fpu_c.patch |  46 ++
 ...ild-fix-use-SIGRTMAX-rather-than-__SIGRTM.patch |  69 +
 .../musl-0009-jdk-musl-has-gethostby_r.patch   |  35 +
 19 files changed, 1037 insertions(+), 4 deletions(-)
 create mode 100644 
recipes-core/openjdk/patches-openjdk-8/0005-hotspot-use-correct-include-for-poll.patch
 create mode 100644 
recipes-core/openjdk/patches-openjdk-8/0006-hotspot-don-t-rely-on-old-SysV-SIGCLD.patch
 create mode 100644 
recipes-core/openjdk/patches-openjdk-8/0007-jdk-use-correct-include-for-poll.patch
 create mode 100644 
recipes-core/openjdk/patches-openjdk-8/0008-jdk-use-correct-include-for-signal.patch
 create mode 100644 
recipes-core/openjdk/patches-openjdk-8/0009-jdk-disable-backtrace-musl-build-fix.patch
 create mode 100644 
recipes-core/openjdk/patches-openjdk-8/musl-0001-hotspot-stop-using-obsolete-isnanf.patch
 create mode 100644 
recipes-core/openjdk/patches-openjdk-8/musl-0002-jdk-give-a-much-bigger-buffer-to-getmntent_r.patch
 create mode 100644 
recipes-core/openjdk/patches-openjdk-8/musl-0003-jdk-fix-libjvm-load-on-musl-set-LD_LIBRARY_PATH.patch
 create mode 100644 
recipes-core/openjdk/patches-openjdk-8/musl-0004-jdk-remove-sysctl.h-include-musl-build-fix.patch
 create mode 100644 
recipes-core/openjdk/patches-openjdk-8/musl-0005-hotspot-disable-agent-build.patch
 create mode 100644 
recipes-core/openjdk/patches-openjdk-8/musl-0006-hotspot-os_linux-remove-glibc-dependencies.patch
 create mode 100644 
recipes-core/openjdk/patches-openjdk-8/musl-0007-hotspot-os_linux_x86-remove-glibc-dependencies-fpu_c.patch
 create mode 100644 
recipes-core/openjdk/patches-openjdk-8/musl-0008-jdk-musl-build-fix-use-SIGRTMAX-rather-than-__SIGRTM.patch
 create mode 100644 
recipes-core/openjdk/patches-openjdk-8/musl-0009-jdk-musl-has-gethostby_r.patch

diff --git a/recipes-core/openjdk/openjdk-8-release-162b12.inc 
b/recipes-core/openjdk/openjdk-8-release-162b12.inc
index d672148..dc1e023 100644
--- a/recipes-core/openjdk/openjdk-8-release-162b12.inc
+++ b/recipes-core/openjdk/openjdk-8-release-162b12.inc
@@ -10,6 +10,11 @@ PATCHES_URI = "\
 file://0002-hotspot-fix-compilation-with-security-flags-enabled.patch \
 file://0003-jdk-Allow-using-a-system-installed-libjpeg.patch \
 file://0004-jdk-Allow-using-a-system-installed-libpng.patch \
+file://0005-hotspot-use-correct-include-for-poll.patch \
+file://0006-hotspot-don-t-rely-on-old-SysV-SIGCLD.patch \
+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 \
 "
 # 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
@@ -23,6 +28,17 @@ PATCHES_URI_append_class-target = "\
 file://openjdk8-add-missing-linker-flags.patch;striplevel=0 \
 file://openjdk8-fix-libpng-neon-build.patch;striplevel=0 \
 "
+PATCHES_URI_append_libc-musl = "\
+file://musl-0001-hotspot-stop-using-obsolete-isnanf.patch \
+file://musl-0002-jdk-give-a-much-bigger-buffer-to-getmntent_r.patch \
+file://musl-0003-jdk-fix-libjvm-load-on-musl-set-LD_LIBRARY_PATH.patch \
+file://musl-0004-jdk-remove-sysctl.h-include-musl-build-fix.patch \
+file://musl-0005-hotspot-disable-agent-build.patch \
+file://musl-0006-hotspot-os_linux-remove-glibc-dependencies.patch \
+
file://musl-0007-hotspot-os_linux_x86-remove-glibc-dependencies-fpu_c.patch \
+
file://musl-0008-jdk-musl-build-fix-use-SIGRTMAX-rather-than-__SIGRTM.patch \
+file://musl-0009-jdk-musl-has-gethostby_r.patch \
+"
 
 # Na

[yocto] [meta-java][PATCH 14/14] openjdk-8: add aarch64 support

2018-03-05 Thread André Draszik

From: André Draszik 

This is using the aarch64 port to make it work, which is at version
u161b15.
We also add one patch to make this work with musl, too.

Because the aarch64 port is fetched from a different
repository, the version specific include has been split so
as to have all common parts (URIs, patches, configuration
bits) in one single file, and version specific bits
(checksum, mercurial commit ID), in another file, to
ease maintenance, and make distinguishing easier.

Signed-off-by: André Draszik 
---
 recipes-core/openjdk/openjdk-8-common.inc  |  2 -
 recipes-core/openjdk/openjdk-8-release-161b15.inc  | 33 
 recipes-core/openjdk/openjdk-8-release-162b12.inc  | 83 +
 recipes-core/openjdk/openjdk-8-release-16xbyy.inc  | 87 ++
 .../{openjdk-8_162b12.bb => openjdk-8_16xbyy.bb}   |  3 +
 .../{openjre-8_162b12.bb => openjre-8_16xbyy.bb}   |  3 +
 .../hotspot-remaining-musl-fixes-aarch64.patch | 35 +
 7 files changed, 164 insertions(+), 82 deletions(-)
 create mode 100644 recipes-core/openjdk/openjdk-8-release-161b15.inc
 create mode 100644 recipes-core/openjdk/openjdk-8-release-16xbyy.inc
 rename recipes-core/openjdk/{openjdk-8_162b12.bb => openjdk-8_16xbyy.bb} (98%)
 rename recipes-core/openjdk/{openjre-8_162b12.bb => openjre-8_16xbyy.bb} (96%)
 create mode 100644 
recipes-core/openjdk/patches-openjdk-8/hotspot-remaining-musl-fixes-aarch64.patch

diff --git a/recipes-core/openjdk/openjdk-8-common.inc 
b/recipes-core/openjdk/openjdk-8-common.inc
index dbdd053..b2020c3 100644
--- a/recipes-core/openjdk/openjdk-8-common.inc
+++ b/recipes-core/openjdk/openjdk-8-common.inc
@@ -199,8 +199,6 @@ def get_jdk_arch(d):
 return jdk_arch
 
 JDK_ARCH = "${@get_jdk_arch(d)}"
-# We do not yet work for aarch64.
-COMPATIBLE_HOST = "^(?!aarch64).*"
 
 export DEBUG_BINARIES = "true"
 
diff --git a/recipes-core/openjdk/openjdk-8-release-161b15.inc 
b/recipes-core/openjdk/openjdk-8-release-161b15.inc
new file mode 100644
index 000..0a4434c
--- /dev/null
+++ b/recipes-core/openjdk/openjdk-8-release-161b15.inc
@@ -0,0 +1,33 @@
+require openjdk-8-release-16xbyy.inc
+
+CORBA_CHANGESET_aarch64 = "f73da600c483"
+SRC_URI[corba.md5sum] = "bf884b82fcc6de466946fcb87d24ebf3"
+SRC_URI[corba.sha256sum] = 
"ebf73d96185fc05e502088ae89a8d6494c3971dd220458deeff3876f72396b6c"
+
+HOTSPOT_CHANGESET_aarch64 = "a600839824fa"
+SRC_URI[hotspot.md5sum] = "20c88ba26f8f45a2769f4edf32afd593"
+SRC_URI[hotspot.sha256sum] = 
"6d0d1b9c2df3392ad6e21ca3eae39d06b50632a4a419da3d4363248943ea8b97"
+
+JAXP_CHANGESET_aarch64 = "b1e2af899046"
+SRC_URI[jaxp.md5sum] = "219582b26d7de2973b75f4329b53ec7d"
+SRC_URI[jaxp.sha256sum] = 
"907cc4dfb01a3a2a6d74dfa90fa6fcb5b3df55600f41ba44dcdc94b47e85a382"
+
+JAXWS_CHANGESET_aarch64 = "0002ed323fe5"
+SRC_URI[jaxws.md5sum] = "44935b81e3405fcaef675d5d08c2149e"
+SRC_URI[jaxws.sha256sum] = 
"0d1d52f1cf254a643ece1bd6cd8628fae1a4d56e8b59388cc9ad73b3caf151a1"
+
+JDK_CHANGESET_aarch64 = "c2ba2ed87d18"
+SRC_URI[jdk.md5sum] = "f4c0393a157dcb8b90ee7c7d80cbdfbf"
+SRC_URI[jdk.sha256sum] = 
"c84a17451b47242f9d96bf431011607afc3776f285a6ad9a60190fba2d434c49"
+
+LANGTOOLS_CHANGESET_aarch64 = "cdb217c578cb"
+SRC_URI[langtools.md5sum] = "608cf07781259d916d1663d6a5ced26d"
+SRC_URI[langtools.sha256sum] = 
"ad28e75bfaba1b64fdd02ea316db3ba3cba68007f90c5fa2be2418ce8bc0074d"
+
+NASHORN_CHANGESET_aarch64 = "505d0eb2fafe"
+SRC_URI[nashorn.md5sum] = "be981a6c55f9e602ff129fed65505a8c"
+SRC_URI[nashorn.sha256sum] = 
"14419ccd773e1db83b600d05aca3cbac9f24be77abda9a132d12305d8821d6d7"
+
+OPENJDK_CHANGESET_aarch64 = "917454da25c1"
+SRC_URI[openjdk.md5sum] = "1e4b3eca032742b7448731f9b8fcb426"
+SRC_URI[openjdk.sha256sum] = 
"1e17e2d8384a7b808a89b982e7c09c4feb8598b7a66b93697bfb8759c1005974"
diff --git a/recipes-core/openjdk/openjdk-8-release-162b12.inc 
b/recipes-core/openjdk/openjdk-8-release-162b12.inc
index dc1e023..bc2b342 100644
--- a/recipes-core/openjdk/openjdk-8-release-162b12.inc
+++ b/recipes-core/openjdk/openjdk-8-release-162b12.inc
@@ -1,58 +1,7 @@
-PATCHES_URI = "\
-file://remove-shell-variables-from-autoheader.patch;striplevel=0 \
-file://filter-aclocal-copy-too.patch;striplevel=0 \
-file://dont-expect-fqpn-for-make.patch;striplevel=0 \
-file://openjdk8-no-genx11-in-headless.patch;striplevel=0 \
-file://openjdk8-no-unused-deps.patch;striplevel=0 \
-file://openjdk8-find-compiler-fix-env-respect.patch;striplevel=0 \
-
file://openjdk8-prevent-debuginfo-in-favour-of-openembedded-package-split.patch;striplevel=0
 \
-file://0001-jdk-comparison-between-pointer-and-integer.patch \
-file://0002-hotspot-fix-compilation-with-security-flags-enabled.patch \
-file://0003-jdk-Allow-using-a-system-installed-libjpeg.patch \
-file://0004-jdk-Allow-using-a-system-installed-libpng.patch \
-file://0005-hotspot-use-correct-include-for-poll.patch \
-file://0006-hotspot-don-t-rely-on-old-SysV-SIGCLD.patch \
-file://0007-jdk-use-correct-includ

[yocto] [meta-java][PATCH 08/14] openjdk-8: add patches to support building against system libpng & libjpeg

2018-03-05 Thread André Draszik

From: André Draszik 

This didn't actually before. Patches taken from Debian / OpenJDK-9.

Signed-off-by: André Draszik 
---
 recipes-core/openjdk/openjdk-8-cross.inc   |   5 +-
 recipes-core/openjdk/openjdk-8-native.inc  |   6 +-
 recipes-core/openjdk/openjdk-8-release-162b12.inc  |   2 +
 ...dk-Allow-using-a-system-installed-libjpeg.patch | 262 +
 ...jdk-Allow-using-a-system-installed-libpng.patch | 148 
 5 files changed, 420 insertions(+), 3 deletions(-)
 create mode 100644 
recipes-core/openjdk/patches-openjdk-8/0003-jdk-Allow-using-a-system-installed-libjpeg.patch
 create mode 100644 
recipes-core/openjdk/patches-openjdk-8/0004-jdk-Allow-using-a-system-installed-libpng.patch

diff --git a/recipes-core/openjdk/openjdk-8-cross.inc 
b/recipes-core/openjdk/openjdk-8-cross.inc
index 3973fcf..40db2eb 100644
--- a/recipes-core/openjdk/openjdk-8-cross.inc
+++ b/recipes-core/openjdk/openjdk-8-cross.inc
@@ -3,7 +3,7 @@ JRE_HOME = "${libdir_jvm}/openjre-8"
 
 DEPENDS = "\
 openjdk-8-native zip-native ant-native libxslt \
-jpeg libpng krb5 libffi fontconfig freetype \
+krb5 libffi fontconfig freetype \
 "
 
 PRIVATE_LIBS = "\
@@ -19,6 +19,7 @@ PACKAGECONFIG ??= " \
 repack \
 ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11 cups', '', d)} \
 ${@bb.utils.contains('DISTRO_FEATURES', 'alsa', 'alsa', '', d)} \
+jpeg png \
 "
 PACKAGECONFIG[x11] = "--with-x,,libx11 xproto libxt libxext libxrender libxtst"
 PACKAGECONFIG[cups] = "--with-cups,,cups"
@@ -28,6 +29,8 @@ PACKAGECONFIG[jce] = "--enable-unlimited-crypto,,"
 
 PACKAGECONFIG[zip] = "--with-zlib=system,--with-zlib=bundled,zlib,"
 PACKAGECONFIG[gif] = "--with-giflib=system,--with-giflib=bundled,giflib,"
+PACKAGECONFIG[jpeg] = "--with-libjpeg=system,--with-libjpeg=bundled,jpeg,"
+PACKAGECONFIG[png] = "--with-libpng=system,--with-libpng=bundled,libpng,"
 
 export WANT_LLVM_RELEASE = "3.5.2"
 PACKAGECONFIG[zero] = "--with-jvm-variants=zero,,,"
diff --git a/recipes-core/openjdk/openjdk-8-native.inc 
b/recipes-core/openjdk/openjdk-8-native.inc
index 20e1743..10b31bc 100644
--- a/recipes-core/openjdk/openjdk-8-native.inc
+++ b/recipes-core/openjdk/openjdk-8-native.inc
@@ -2,7 +2,7 @@ JDK_DIR = "openjdk-8-native"
 DEPENDS = "\
 icedtea7-native ant-native \
 libxslt-native attr-native \
-giflib-native jpeg-native libpng-native \
+giflib-native \
 glib-2.0-native freetype-native fontconfig-native \
 zlib-native zip-native \
 unzip-native make-native \
@@ -11,11 +11,13 @@ DEPENDS = "\
 
 SRC_URI_append += "file://handle_extra_output.patch"
 
-PACKAGECONFIG ??= ""
+PACKAGECONFIG ??= "jpeg png"
 PACKAGECONFIG[x11] = "--with-x,,libx11-native xproto-native libxt-native 
libxext-native libxrender-native"
 PACKAGECONFIG[cups] = "--with-cups,,cups"
 PACKAGECONFIG[alsa] = "--with-alsa,,alsa-lib-native"
 PACKAGECONFIG[jce] = "--enable-unlimited-crypto,,"
+PACKAGECONFIG[jpeg] = 
"--with-libjpeg=system,--with-libjpeg=bundled,jpeg-native"
+PACKAGECONFIG[png] = "--with-libpng=system,--with-libpng=bundled,libpng-native"
 
 EXTRA_OECONF_append = "\
 --with-jobs=${@java_get_parallel_make(d)} \
diff --git a/recipes-core/openjdk/openjdk-8-release-162b12.inc 
b/recipes-core/openjdk/openjdk-8-release-162b12.inc
index a36bc6a..d672148 100644
--- a/recipes-core/openjdk/openjdk-8-release-162b12.inc
+++ b/recipes-core/openjdk/openjdk-8-release-162b12.inc
@@ -8,6 +8,8 @@ PATCHES_URI = "\
 
file://openjdk8-prevent-debuginfo-in-favour-of-openembedded-package-split.patch;striplevel=0
 \
 file://0001-jdk-comparison-between-pointer-and-integer.patch \
 file://0002-hotspot-fix-compilation-with-security-flags-enabled.patch \
+file://0003-jdk-Allow-using-a-system-installed-libjpeg.patch \
+file://0004-jdk-Allow-using-a-system-installed-libpng.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/0003-jdk-Allow-using-a-system-installed-libjpeg.patch
 
b/recipes-core/openjdk/patches-openjdk-8/0003-jdk-Allow-using-a-system-installed-libjpeg.patch
new file mode 100644
index 000..a40e11f
--- /dev/null
+++ 
b/recipes-core/openjdk/patches-openjdk-8/0003-jdk-Allow-using-a-system-installed-libjpeg.patch
@@ -0,0 +1,262 @@
+From a6746c1ee43a63e79b5405e40c463d00160bc02e Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Andr=C3=A9=20Draszik?= 
+Date: Tue, 27 Feb 2018 13:36:53 +
+Subject: [PATCH 3/8] jdk: Allow using a system-installed libjpeg
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Patch stolen (and some typos corrected) from debian patch,
+which itself was a backport from:
+  http://hg.openjdk.java.net/jdk9/client/rev/bfd9a3e1aeb5
+  http://hg.openjdk.java.net/jdk9/client/jdk/rev/320743f0b4fc
+
+Issues fixed on top of debian

[yocto] [meta-java][PATCH 09/14] openjdk-8-native: really use system libgif & zlib

2018-03-05 Thread André Draszik

From: André Draszik 

The intention seems to be to build against above system
libraries, but configure still picked the bundled versions,
even though the libraries are in the sysroot. Make it
deterministic and force use of the system libraries using
PACKAGECONFIG and the appropriate configure arguments.

Signed-off-by: André Draszik 
---
 recipes-core/openjdk/openjdk-8-native.inc | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/recipes-core/openjdk/openjdk-8-native.inc 
b/recipes-core/openjdk/openjdk-8-native.inc
index 10b31bc..d674474 100644
--- a/recipes-core/openjdk/openjdk-8-native.inc
+++ b/recipes-core/openjdk/openjdk-8-native.inc
@@ -2,22 +2,22 @@ JDK_DIR = "openjdk-8-native"
 DEPENDS = "\
 icedtea7-native ant-native \
 libxslt-native attr-native \
-giflib-native \
 glib-2.0-native freetype-native fontconfig-native \
-zlib-native zip-native \
-unzip-native make-native \
+zip-native unzip-native make-native \
 ca-certificates-native openssl-native coreutils-native \
 "
 
 SRC_URI_append += "file://handle_extra_output.patch"
 
-PACKAGECONFIG ??= "jpeg png"
+PACKAGECONFIG ??= "gif jpeg png zlib"
 PACKAGECONFIG[x11] = "--with-x,,libx11-native xproto-native libxt-native 
libxext-native libxrender-native"
 PACKAGECONFIG[cups] = "--with-cups,,cups"
 PACKAGECONFIG[alsa] = "--with-alsa,,alsa-lib-native"
+PACKAGECONFIG[gif] = "--with-giflib=system,--with-giflib=bundled,giflib-native"
 PACKAGECONFIG[jce] = "--enable-unlimited-crypto,,"
 PACKAGECONFIG[jpeg] = 
"--with-libjpeg=system,--with-libjpeg=bundled,jpeg-native"
 PACKAGECONFIG[png] = "--with-libpng=system,--with-libpng=bundled,libpng-native"
+PACKAGECONFIG[zlib] = "--with-zlib=system,--with-zlib=bundled,zlib-native"
 
 EXTRA_OECONF_append = "\
 --with-jobs=${@java_get_parallel_make(d)} \
-- 
2.16.2

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

[yocto] [meta-java][PATCH 12/14] openjdk-8: stop passing obsolete make variables (freetype)

2018-03-05 Thread André Draszik

From: André Draszik 

OpenJDK's build system complains about passing in obsolete ALT_
variables.
Stop passing in those for freetype, as pkg-config is used to figure
out the correct compiler and linker flags.

Signed-off-by: André Draszik 
---
 recipes-core/openjdk/openjdk-8-cross.inc | 2 --
 1 file changed, 2 deletions(-)

diff --git a/recipes-core/openjdk/openjdk-8-cross.inc 
b/recipes-core/openjdk/openjdk-8-cross.inc
index 922c2ae..d70c946 100644
--- a/recipes-core/openjdk/openjdk-8-cross.inc
+++ b/recipes-core/openjdk/openjdk-8-cross.inc
@@ -99,8 +99,6 @@ EXTRA_OEMAKE_append = '\
 ${@jdk_make_options(d)} \
 ALT_SDT_H="${STAGING_INCDIR}" \
 ALT_CUPS_HEADERS_PATH="${STAGING_INCDIR}" \
-ALT_FREETYPE_HEADERS_PATH="${STAGING_INCDIR}/freetype2" \
-ALT_FREETYPE_LIB_PATH="${STAGING_LIBDIR}" \
 STRIP_POLICY=no_strip \
 MAKE_VERBOSE=y VERBOSE=-s LOG_LEVEL=trace \
 QUIETLY= \
-- 
2.16.2

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

[yocto] [meta-java][PATCH 11/14] openjdk-8: rename PACKAGECONFIG zip -> zlib

2018-03-05 Thread André Draszik

From: André Draszik 

The existing PACKAGECONFIG option 'zip' affects OpenJDK's
usage of zlib, not zip, so this option is a bit inconsistent
and confusing.

Rename to zlib.

Signed-off-by: André Draszik 
---
 recipes-core/openjdk/openjdk-8-cross.inc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/recipes-core/openjdk/openjdk-8-cross.inc 
b/recipes-core/openjdk/openjdk-8-cross.inc
index 8a24b14..922c2ae 100644
--- a/recipes-core/openjdk/openjdk-8-cross.inc
+++ b/recipes-core/openjdk/openjdk-8-cross.inc
@@ -19,7 +19,7 @@ PACKAGECONFIG ??= " \
 repack \
 ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11 cups', '', d)} \
 ${@bb.utils.contains('DISTRO_FEATURES', 'alsa', 'alsa', '', d)} \
-gif jpeg png zip \
+gif jpeg png zlib \
 "
 PACKAGECONFIG[x11] = "--with-x,,libx11 xproto libxt libxext libxrender libxtst"
 PACKAGECONFIG[cups] = "--with-cups,,cups"
@@ -27,10 +27,10 @@ PACKAGECONFIG[alsa] = "--with-alsa,,alsa-lib"
 
 PACKAGECONFIG[jce] = "--enable-unlimited-crypto,,"
 
-PACKAGECONFIG[zip] = "--with-zlib=system,--with-zlib=bundled,zlib,"
 PACKAGECONFIG[gif] = "--with-giflib=system,--with-giflib=bundled,giflib,"
 PACKAGECONFIG[jpeg] = "--with-libjpeg=system,--with-libjpeg=bundled,jpeg,"
 PACKAGECONFIG[png] = "--with-libpng=system,--with-libpng=bundled,libpng,"
+PACKAGECONFIG[zlib] = "--with-zlib=system,--with-zlib=bundled,zlib,"
 
 export WANT_LLVM_RELEASE = "3.5.2"
 PACKAGECONFIG[zero] = "--with-jvm-variants=zero,,,"
-- 
2.16.2

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

[yocto] [meta-java][PATCH 10/14] openjdk-8: build against system libgif & zlib by default

2018-03-05 Thread André Draszik

From: André Draszik 

This should really be the default so as to benefit from CVE fixes
etc.

Signed-off-by: André Draszik 
---
 recipes-core/openjdk/openjdk-8-cross.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-core/openjdk/openjdk-8-cross.inc 
b/recipes-core/openjdk/openjdk-8-cross.inc
index 40db2eb..8a24b14 100644
--- a/recipes-core/openjdk/openjdk-8-cross.inc
+++ b/recipes-core/openjdk/openjdk-8-cross.inc
@@ -19,7 +19,7 @@ PACKAGECONFIG ??= " \
 repack \
 ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11 cups', '', d)} \
 ${@bb.utils.contains('DISTRO_FEATURES', 'alsa', 'alsa', '', d)} \
-jpeg png \
+gif jpeg png zip \
 "
 PACKAGECONFIG[x11] = "--with-x,,libx11 xproto libxt libxext libxrender libxtst"
 PACKAGECONFIG[cups] = "--with-cups,,cups"
-- 
2.16.2

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

[yocto] [meta-java][PATCH 07/14] openjdk-8: add patch for compiling with enabled security flags

2018-03-05 Thread André Draszik

From: André Draszik 

Rather than carrying an OE specific patch that just silences the
warning on some platform only, backport the upstream patch
to actually fix the issue.

Signed-off-by: André Draszik 
---
 recipes-core/openjdk/openjdk-8-release-162b12.inc  |  2 +-
 ...x-compilation-with-security-flags-enabled.patch | 41 
 ...openjdk8-silence-d_fortify_source-warning.patch | 56 --
 3 files changed, 42 insertions(+), 57 deletions(-)
 create mode 100644 
recipes-core/openjdk/patches-openjdk-8/0002-hotspot-fix-compilation-with-security-flags-enabled.patch
 delete mode 100644 
recipes-core/openjdk/patches-openjdk-8/openjdk8-silence-d_fortify_source-warning.patch

diff --git a/recipes-core/openjdk/openjdk-8-release-162b12.inc 
b/recipes-core/openjdk/openjdk-8-release-162b12.inc
index 5a577b9..a36bc6a 100644
--- a/recipes-core/openjdk/openjdk-8-release-162b12.inc
+++ b/recipes-core/openjdk/openjdk-8-release-162b12.inc
@@ -7,6 +7,7 @@ PATCHES_URI = "\
 file://openjdk8-find-compiler-fix-env-respect.patch;striplevel=0 \
 
file://openjdk8-prevent-debuginfo-in-favour-of-openembedded-package-split.patch;striplevel=0
 \
 file://0001-jdk-comparison-between-pointer-and-integer.patch \
+file://0002-hotspot-fix-compilation-with-security-flags-enabled.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
@@ -17,7 +18,6 @@ PATCHES_URI_append_class-target = "\
 file://openjdk8-fix-shark-stdc++11.patch;striplevel=0 \
 file://openjdk8-fix-assembler-flag-handling-in-makefile.patch;striplevel=0 
\
 file://openjdk8-fix-adlc-flags.patch;striplevel=0 \
-file://openjdk8-silence-d_fortify_source-warning.patch;striplevel=0 \
 file://openjdk8-add-missing-linker-flags.patch;striplevel=0 \
 file://openjdk8-fix-libpng-neon-build.patch;striplevel=0 \
 "
diff --git 
a/recipes-core/openjdk/patches-openjdk-8/0002-hotspot-fix-compilation-with-security-flags-enabled.patch
 
b/recipes-core/openjdk/patches-openjdk-8/0002-hotspot-fix-compilation-with-security-flags-enabled.patch
new file mode 100644
index 000..f06e791
--- /dev/null
+++ 
b/recipes-core/openjdk/patches-openjdk-8/0002-hotspot-fix-compilation-with-security-flags-enabled.patch
@@ -0,0 +1,41 @@
+From bdea8cf299313388ec41ea20281deca6dc4f764d Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Andr=C3=A9=20Draszik?= 
+Date: Tue, 27 Feb 2018 14:41:06 +
+Subject: [PATCH 2/8] hotspot: fix compilation with security flags enabled
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+| hotspot/src/share/vm/code/dependencies.cpp: In function 'static void 
Dependencies::write_dependency_to(xmlStream*, Dependencies::DepType, 
GrowableArray*, Klass*)':
+| hotspot/src/share/vm/code/dependencies.cpp:498:6: error: '%d' directive 
writing between 1 and 10 bytes into a region of size 9 
[-Werror=format-overflow=]
+|  void Dependencies::write_dependency_to(xmlStream* xtty,
+|   ^~~~
+| hotspot/src/share/vm/code/dependencies.cpp:498:6: note: directive argument 
in the range [0, 2147483647]
+| hotspot/src/share/vm/code/dependencies.cpp:528:27: note: 'sprintf' output 
between 3 and 12 bytes into a destination of size 10
+|char xn[10]; sprintf(xn, "x%d", j);
+| ~~~^~
+
+Backport a patch to fix this.
+
+Upstream-Status: Backport 
[http://hg.openjdk.java.net/jdk10/jdk10/hotspot/rev/eb11b3f0ae65]
+Signed-off-by: André Draszik 
+---
+ hotspot/src/share/vm/code/dependencies.cpp | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/hotspot/src/share/vm/code/dependencies.cpp 
b/hotspot/src/share/vm/code/dependencies.cpp
+index 7317036d..c71d921d 100644
+--- a/hotspot/src/share/vm/code/dependencies.cpp
 b/hotspot/src/share/vm/code/dependencies.cpp
+@@ -525,7 +525,7 @@ void Dependencies::write_dependency_to(xmlStream* xtty,
+ xtty->object("x", arg.metadata_value());
+   }
+ } else {
+-  char xn[10]; sprintf(xn, "x%d", j);
++  char xn[12]; sprintf(xn, "x%d", j);
+   if (arg.is_oop()) {
+ xtty->object(xn, arg.oop_value());
+   } else {
+-- 
+2.16.2
+
diff --git 
a/recipes-core/openjdk/patches-openjdk-8/openjdk8-silence-d_fortify_source-warning.patch
 
b/recipes-core/openjdk/patches-openjdk-8/openjdk8-silence-d_fortify_source-warning.patch
deleted file mode 100644
index 2c2e333..000
--- 
a/recipes-core/openjdk/patches-openjdk-8/openjdk8-silence-d_fortify_source-warning.patch
+++ /dev/null
@@ -1,56 +0,0 @@
-makefiles: Add -Wno-cpp to CFLAGS
-
-The security flag '-D_FORTIFY_SOURCE' requires at least -O to work,
-otherwise a warning is given. If CFLAGS additionally contains -Werror,
-this warning turns into an error. As Openjdk build system intentionally
-deoptimizes certains files due to potential bad codegen during optimization,
-

[yocto] [meta-java][PATCH 06/14] openjdk-8: fix a compiler warning

2018-03-05 Thread André Draszik

From: André Draszik 

As per the patch

Signed-off-by: André Draszik 
---
 recipes-core/openjdk/openjdk-8-release-162b12.inc  |   1 +
 ...dk-comparison-between-pointer-and-integer.patch | 144 +
 2 files changed, 145 insertions(+)
 create mode 100644 
recipes-core/openjdk/patches-openjdk-8/0001-jdk-comparison-between-pointer-and-integer.patch

diff --git a/recipes-core/openjdk/openjdk-8-release-162b12.inc 
b/recipes-core/openjdk/openjdk-8-release-162b12.inc
index b7e6392..5a577b9 100644
--- a/recipes-core/openjdk/openjdk-8-release-162b12.inc
+++ b/recipes-core/openjdk/openjdk-8-release-162b12.inc
@@ -6,6 +6,7 @@ PATCHES_URI = "\
 file://openjdk8-no-unused-deps.patch;striplevel=0 \
 file://openjdk8-find-compiler-fix-env-respect.patch;striplevel=0 \
 
file://openjdk8-prevent-debuginfo-in-favour-of-openembedded-package-split.patch;striplevel=0
 \
+file://0001-jdk-comparison-between-pointer-and-integer.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/0001-jdk-comparison-between-pointer-and-integer.patch
 
b/recipes-core/openjdk/patches-openjdk-8/0001-jdk-comparison-between-pointer-and-integer.patch
new file mode 100644
index 000..29a30d6
--- /dev/null
+++ 
b/recipes-core/openjdk/patches-openjdk-8/0001-jdk-comparison-between-pointer-and-integer.patch
@@ -0,0 +1,144 @@
+From 97d6911fb581f9e44785db29abbf97ce77713f50 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Andr=C3=A9=20Draszik?= 
+Date: Fri, 2 Mar 2018 11:13:08 +
+Subject: [PATCH 1/8] jdk: comparison between pointer and integer
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+In file included from jdk/src/share/native/java/net/net_util.c:28:0:
+jdk/src/share/native/java/net/net_util.c: In function 
'NET_SockaddrToInetAddress':
+jdk/src/share/native/common/jni_util.h:302:17: warning: comparison between 
pointer and integer
+ if ((x) == NULL) {  \
+ ^
+jdk/src/share/native/java/net/net_util.c:225:13: note: in expansion of macro 
'CHECK_NULL_RETURN'
+ CHECK_NULL_RETURN(ret, NULL);
+ ^
+
+Backport a patch to fix this.
+
+Upstream-Status: Backport 
[http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/90c643593ed7]
+Signed-off-by: André Draszik 
+---
+ jdk/src/share/native/java/net/net_util.c   | 15 +++
+ jdk/src/share/native/java/net/net_util.h   |  8 
+ jdk/src/solaris/native/java/net/Inet6AddressImpl.c |  4 ++--
+ 3 files changed, 13 insertions(+), 14 deletions(-)
+
+diff --git a/jdk/src/share/native/java/net/net_util.c 
b/jdk/src/share/native/java/net/net_util.c
+index 2194e2e6..00c9e2ac 100644
+--- a/jdk/src/share/native/java/net/net_util.c
 b/jdk/src/share/native/java/net/net_util.c
+@@ -108,7 +108,7 @@ jobject getInet6Address_scopeifname(JNIEnv *env, jobject 
iaObj) {
+ return (*env)->GetObjectField(env, holder, ia6_scopeifnameID);
+ }
+ 
+-int setInet6Address_scopeifname(JNIEnv *env, jobject iaObj, jobject 
scopeifname) {
++jboolean setInet6Address_scopeifname(JNIEnv *env, jobject iaObj, jobject 
scopeifname) {
+ jobject holder = (*env)->GetObjectField(env, iaObj, ia6_holder6ID);
+ CHECK_NULL_RETURN(holder, JNI_FALSE);
+ (*env)->SetObjectField(env, holder, ia6_scopeifnameID, scopeifname);
+@@ -127,7 +127,7 @@ int getInet6Address_scopeid(JNIEnv *env, jobject iaObj) {
+ return (*env)->GetIntField(env, holder, ia6_scopeidID);
+ }
+ 
+-int setInet6Address_scopeid(JNIEnv *env, jobject iaObj, int scopeid) {
++jboolean setInet6Address_scopeid(JNIEnv *env, jobject iaObj, int scopeid) {
+ jobject holder = (*env)->GetObjectField(env, iaObj, ia6_holder6ID);
+ CHECK_NULL_RETURN(holder, JNI_FALSE);
+ (*env)->SetIntField(env, holder, ia6_scopeidID, scopeid);
+@@ -138,7 +138,7 @@ int setInet6Address_scopeid(JNIEnv *env, jobject iaObj, 
int scopeid) {
+ }
+ 
+ 
+-int getInet6Address_ipaddress(JNIEnv *env, jobject iaObj, char *dest) {
++jboolean getInet6Address_ipaddress(JNIEnv *env, jobject iaObj, char *dest) {
+ jobject holder, addr;
+ jbyteArray barr;
+ 
+@@ -150,7 +150,7 @@ int getInet6Address_ipaddress(JNIEnv *env, jobject iaObj, 
char *dest) {
+ return JNI_TRUE;
+ }
+ 
+-int setInet6Address_ipaddress(JNIEnv *env, jobject iaObj, char *address) {
++jboolean setInet6Address_ipaddress(JNIEnv *env, jobject iaObj, char *address) 
{
+ jobject holder;
+ jbyteArray addr;
+ 
+@@ -202,7 +202,6 @@ NET_SockaddrToInetAddress(JNIEnv *env, struct sockaddr 
*him, int *port) {
+ jobject iaObj;
+ #ifdef AF_INET6
+ if (him->sa_family == AF_INET6) {
+-jbyteArray ipaddress;
+ #ifdef WIN32
+ struct SOCKADDR_IN6 *him6 = (struct SOCKADDR_IN6 *)him;
+ #else
+@@ -218,11 +217,12 @@ NET_SockaddrToInetAddress

[yocto] [meta-java][PATCH 05/14] openjdk-8: rework do_patch (pt 2 - use bitbake variable overrides)

2018-03-05 Thread André Draszik

From: André Draszik 

This currently uses a hand-crafted solution to distinguish
between common, native-only and and target-only patches.
That is a bit hard to follow as patches are being applied in
strange order, and is also non-standard.

Instead, we can just use bitbake variable overrides. This
makes it much easier to work with this recipe, as:
* it is clear in which order patches are going to be applied by
  looking at the recipe
* it is clear which patches are meant to be common, for build,
  or target
* old patches that are still lying around in WORKDIR (e.g.
  because rm_work is not enabled), but that have been removed
  from SRC_URI are no longer incorrectly applied
* if patches fail to apply, we know exactly which patch has
  failed
* we can use PATCHTOOL = without any ill effects

Signed-off-by: André Draszik 
---
 recipes-core/openjdk/openjdk-8-common.inc | 10 --
 recipes-core/openjdk/openjdk-8-cross.inc  | 14 --
 recipes-core/openjdk/openjdk-8-release-162b12.inc | 23 ++-
 3 files changed, 18 insertions(+), 29 deletions(-)

diff --git a/recipes-core/openjdk/openjdk-8-common.inc 
b/recipes-core/openjdk/openjdk-8-common.inc
index cf14be9..dbdd053 100644
--- a/recipes-core/openjdk/openjdk-8-common.inc
+++ b/recipes-core/openjdk/openjdk-8-common.inc
@@ -155,16 +155,6 @@ def jdk_configure_options(d):
 do_unpack[postfuncs] += "do_unpack_extract_submodules"
 do_unpack[postfuncs] += "${@bb.utils.contains('PACKAGECONFIG', 'x11', '', 
'do_unpack_remove_X11_wrappers', d)}"
 
-do_patch_openjdk8() {
-olddir=`pwd`
-cd "${S}"
-for OJ8P in ${WORKDIR}/openjdk8-*.patch; do
-patch -p0 < ${OJ8P}
-done
-}
-
-do_patch[postfuncs] += "do_patch_openjdk8"
-
 do_configure_prepend() {
 export ${@jdk_environment_options(d)}
 }
diff --git a/recipes-core/openjdk/openjdk-8-cross.inc 
b/recipes-core/openjdk/openjdk-8-cross.inc
index 65e3a98..3973fcf 100644
--- a/recipes-core/openjdk/openjdk-8-cross.inc
+++ b/recipes-core/openjdk/openjdk-8-cross.inc
@@ -1,20 +1,6 @@
 JDK_HOME = "${libdir_jvm}/openjdk-8"
 JRE_HOME = "${libdir_jvm}/openjre-8"
 
-# 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
-# by Roman Kennke (rkennke at redhat.com)
-PATCHES_URI_append = "\
-file://openjdk8-restrict-to-staging-dir.patch;apply=no \
-file://openjdk8-fix-shark-build.patch;apply=no \
-file://openjdk8-fix-shark-stdc++11.patch;apply=no \
-file://openjdk8-fix-assembler-flag-handling-in-makefile.patch;apply=no \
-file://openjdk8-fix-adlc-flags.patch;apply=no \
-file://openjdk8-silence-d_fortify_source-warning.patch;apply=no \
-file://openjdk8-add-missing-linker-flags.patch;apply=no \
-file://openjdk8-fix-libpng-neon-build.patch;apply=no \
-"
-
 DEPENDS = "\
 openjdk-8-native zip-native ant-native libxslt \
 jpeg libpng krb5 libffi fontconfig freetype \
diff --git a/recipes-core/openjdk/openjdk-8-release-162b12.inc 
b/recipes-core/openjdk/openjdk-8-release-162b12.inc
index c8f6ad1..b7e6392 100644
--- a/recipes-core/openjdk/openjdk-8-release-162b12.inc
+++ b/recipes-core/openjdk/openjdk-8-release-162b12.inc
@@ -1,11 +1,24 @@
-PATCHES_URI="\
+PATCHES_URI = "\
 file://remove-shell-variables-from-autoheader.patch;striplevel=0 \
 file://filter-aclocal-copy-too.patch;striplevel=0 \
 file://dont-expect-fqpn-for-make.patch;striplevel=0 \
-file://openjdk8-no-genx11-in-headless.patch;apply=no \
-file://openjdk8-no-unused-deps.patch;apply=no \
-file://openjdk8-find-compiler-fix-env-respect.patch;apply=no \
-
file://openjdk8-prevent-debuginfo-in-favour-of-openembedded-package-split.patch;apply=no
 \
+file://openjdk8-no-genx11-in-headless.patch;striplevel=0 \
+file://openjdk8-no-unused-deps.patch;striplevel=0 \
+file://openjdk8-find-compiler-fix-env-respect.patch;striplevel=0 \
+
file://openjdk8-prevent-debuginfo-in-favour-of-openembedded-package-split.patch;striplevel=0
 \
+"
+# 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
+# by Roman Kennke (rkennke at redhat.com)
+PATCHES_URI_append_class-target = "\
+file://openjdk8-restrict-to-staging-dir.patch;striplevel=0 \
+file://openjdk8-fix-shark-build.patch;striplevel=0 \
+file://openjdk8-fix-shark-stdc++11.patch;striplevel=0 \
+file://openjdk8-fix-assembler-flag-handling-in-makefile.patch;striplevel=0 
\
+file://openjdk8-fix-adlc-flags.patch;striplevel=0 \
+file://openjdk8-silence-d_fortify_source-warning.patch;striplevel=0 \
+file://openjdk8-add-missing-linker-flags.patch;striplevel=0 \
+file://openjdk8-fix-libpng-neon-build.patch;striplevel=0 \
 "
 
 # Name of the directory containing the com

[yocto] [meta-java][PATCH 04/14] openjdk-8: rework do_patch (pt 1 - X11 wrappers)

2018-03-05 Thread André Draszik

From: André Draszik 

X11 wrappers are currently being deleted using a custom
do_patch[postfuncs]. This is confusing to say the least,
as e.g. naming implies this is done after ./configure
has run.

At the moment, this also happens halfway through
patches have been applied, i.e. some patches are being
applied, then the X11 wrappers are deleted, then
more patches are being applied.

Streamline this so that the unneeded wrappers are
removed as part of do_unpack[postfuncs].

Signed-off-by: André Draszik 
---
 recipes-core/openjdk/openjdk-8-common.inc | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/recipes-core/openjdk/openjdk-8-common.inc 
b/recipes-core/openjdk/openjdk-8-common.inc
index ab4c870..cf14be9 100644
--- a/recipes-core/openjdk/openjdk-8-common.inc
+++ b/recipes-core/openjdk/openjdk-8-common.inc
@@ -39,6 +39,10 @@ do_unpack_extract_submodules () {
 tar xjf ${WORKDIR}/${NASHORN_FILE} --transform "s,-${NASHORN_CHANGESET},,g"
 }
 
+do_unpack_remove_X11_wrappers() {
+find ${S}/jdk/src/solaris/classes/sun/awt/X11 -maxdepth 1 -name '*.java' 
-delete
+}
+
 def package_config_option_cleanup(d):
 distro_x11 = bb.utils.contains('DISTRO_FEATURES', 'x11', True, False, d)
 distro_alsa = bb.utils.contains('DISTRO_FEATURES', 'alsa', True, False, d)
@@ -149,13 +153,11 @@ def jdk_configure_options(d):
 return options[3]
 
 do_unpack[postfuncs] += "do_unpack_extract_submodules"
-
-POST_CONFIGURE_CLEAN_X11 = "${@bb.utils.contains('PACKAGECONFIG', 'x11', '', 
'rm -f jdk/src/solaris/classes/sun/awt/X11/*.java', d)}"
+do_unpack[postfuncs] += "${@bb.utils.contains('PACKAGECONFIG', 'x11', '', 
'do_unpack_remove_X11_wrappers', d)}"
 
 do_patch_openjdk8() {
 olddir=`pwd`
 cd "${S}"
-${POST_CONFIGURE_CLEAN_X11}
 for OJ8P in ${WORKDIR}/openjdk8-*.patch; do
 patch -p0 < ${OJ8P}
 done
-- 
2.16.2

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

[yocto] [meta-java][PATCH 02/14] openjdk-8: doesn't compile on aarch64

2018-03-05 Thread André Draszik

From: André Draszik 

OpenJDK's build system just doesn't support it (it somehow picks
compiler flags for am64 builds, which are invalid for aarch64).

Signed-off-by: André Draszik 
---
 recipes-core/openjdk/openjdk-8-common.inc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/recipes-core/openjdk/openjdk-8-common.inc 
b/recipes-core/openjdk/openjdk-8-common.inc
index 19f5103..38a59f4 100644
--- a/recipes-core/openjdk/openjdk-8-common.inc
+++ b/recipes-core/openjdk/openjdk-8-common.inc
@@ -207,6 +207,8 @@ def get_jdk_arch(d):
 return jdk_arch
 
 JDK_ARCH = "${@get_jdk_arch(d)}"
+# We do not yet work for aarch64.
+COMPATIBLE_HOST = "^(?!aarch64).*"
 
 export DEBUG_BINARIES = "true"
 
-- 
2.16.2

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

[yocto] [meta-java][PATCH 01/14] openjdk-8: clarify a bitbake warning

2018-03-05 Thread André Draszik

From: André Draszik 

We get a bitbake warning during recipe building complaining about
unsupported architectures unconditionally. That check is relevant
only for shark builds, so it is quite confusing for non-shark
builds.

Make the warning conditional on whether shark builds are enabled
or not.

Signed-off-by: André Draszik 
---
 recipes-core/openjdk/openjdk-8-common.inc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/recipes-core/openjdk/openjdk-8-common.inc 
b/recipes-core/openjdk/openjdk-8-common.inc
index 070ffaa..19f5103 100644
--- a/recipes-core/openjdk/openjdk-8-common.inc
+++ b/recipes-core/openjdk/openjdk-8-common.inc
@@ -181,7 +181,8 @@ def get_llvm_configure_arch(d):
 elif arch == "powerpc" or arch == "powerpc64":
 arch = "powerpc"
 else:
-bb.warn("%s does not support %s yet" % (d.getVar('PN', True), arch) );
+if 'shark' in d.getVar('PACKAGECONFIG').split():
+bb.warn("%s does not support %s in Shark builds yet" % 
(d.getVar('PN', True), arch) );
 
 return arch
 
-- 
2.16.2

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

[yocto] [meta-java][PATCH 00/14] openjdk-8 updates

2018-03-05 Thread André Draszik

Hi,

OpenJDK8 in yocto is a bit outdated, so these patches
- update openjdk-8 from the 1.5 year old version 102b14 to the
  current 162b12
- modernize the recipe using bitbake variable overrides
- enable building with 'security' flags enabled
- fix the aarch64 build (by using the aarch64 port, which is
  still separate in the OpenJDK8 series)
- fix the musl build (by adding appropriate patches)

This was runtime-tested on x86-64 with both glibc and musl
against the 'poky' DISTRO, and compile-tested on aarch64
against glibc and musl.

Cheers,
Andre'

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

Re: [yocto] Run application at system boot

2018-03-05 Thread Vineeth Karumanchi


Hi ,

On 12/05/2017 07:51 PM, Laurentiu-Cristian Duca wrote:

Hello yocto community,

   I want to know a few things
about how to configure yocto such that
- a simple application (let's say a hello world C program
from a new recipe) is run at boot time.


use update-rc.d class

INITSCRIPT_NAME = "myapp-init"
INITSCRIPT_PARAM = "start 99 S ."

and also install your app in init.d

Thanks
VIneeth


- run a kernel module from a simple recipe at boot time
and automatically build its "/dev/hello" interface file
(which normally is done by hand using mknod).

   I appreciate any hint, example or tutorial regarding this questions.

Thank you very much,
Laurentiu



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

39 matches

Mail list logo