Re: [yocto] Targeting Windows platform

2018-03-13 Thread Florian Doersch

Hi Isaac,

here we also have a mixture of embedded and desktop applications. We use 
yocto for our embedded devices (Xilinx Zynq, Raspberry Pi, Gumstix).


The SDKs and images are very helpful for (cross platform) CI and deployment.

A first milestone definitly would be having a minimal platform support 
for windows, so windows binaries can be built via mingw.


I see 2 steps there:
- cross build on a unix host
- native build on windows

A real Windows SDK support would be awesome (exspecially for deploying 
library dependencies)


I think some "zip" images would be a good start for "image"-deployment. 
I see the support for WiX-Installer second.


There is already some kind of "first try" with the mingw meta layer at 
http://git.yoctoproject.org/cgit.cgi/meta-mingw - but I tried to use it 
with our windows projects and failed, since the mingw version there is 
extremly old.


Regards
Florian


Am 14.03.2018 um 05:15 schrieb Isaac Nickaein:

I know the idea is wild and possibly not a top priority (or even
priority) of the community, but extending the area of Yocto to support
Windows platform can make it the ubiquitous build system for the
enterprise, especially in embedded companies that have a mixture of
embedded and desktop applications.

In our company, we have adopted Yocto to be our build system for
embedded devices and are starting to use it for constant integration
and version management. It also solves the headache of setting up an
C++ environment  by building and provding an SDK that covers a large
set of libraries.

Having a unified build system can hugely simplify the build
management, version control and integration for large organizations
where various platforms are targeted. Yocto has proven to be a great
tool for this and I believe it has potential to cover this area too.

While Yocto is mainly used to build *images* for embedded targets, for
Windows platform it would be enough to build the binaries for
applications, at the first milestone at least. One can also extend it
to build setup files with tools such as WiX installer scripts. So, it
can be break down into:

1. Supporting a bbclass that creates Windows-compatible binaries. With
the help of compilers like mingw, there is the possibility.

2. Creating an SDK that targets Windows.

3. Adapting recipes to be able to build the sources for Windows (for
the cross-platform sources, this would be straight-forward).


I am not sure how much of effort these steps would take and what are
the obstacles. I would be glad to hear from community on what they
think and why this would or not happen.



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


[yocto] Targeting Windows platform

2018-03-13 Thread Isaac Nickaein
I know the idea is wild and possibly not a top priority (or even
priority) of the community, but extending the area of Yocto to support
Windows platform can make it the ubiquitous build system for the
enterprise, especially in embedded companies that have a mixture of
embedded and desktop applications.

In our company, we have adopted Yocto to be our build system for
embedded devices and are starting to use it for constant integration
and version management. It also solves the headache of setting up an
C++ environment  by building and provding an SDK that covers a large
set of libraries.

Having a unified build system can hugely simplify the build
management, version control and integration for large organizations
where various platforms are targeted. Yocto has proven to be a great
tool for this and I believe it has potential to cover this area too.

While Yocto is mainly used to build *images* for embedded targets, for
Windows platform it would be enough to build the binaries for
applications, at the first milestone at least. One can also extend it
to build setup files with tools such as WiX installer scripts. So, it
can be break down into:

1. Supporting a bbclass that creates Windows-compatible binaries. With
the help of compilers like mingw, there is the possibility.

2. Creating an SDK that targets Windows.

3. Adapting recipes to be able to build the sources for Windows (for
the cross-platform sources, this would be straight-forward).


I am not sure how much of effort these steps would take and what are
the obstacles. I would be glad to hear from community on what they
think and why this would or not happen.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


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

2018-03-13 Thread Maxin B. John
Hi André,

On Mon, Mar 12, 2018 at 04:38:05PM +, André Draszik wrote:
> 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}"
> --

Merged, Thanks.

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


Re: [yocto] Two packages installing same file (with different content) to rootfs

2018-03-13 Thread Vuille, Martin (Martin)
Tracked down the problem to the fact that conflict checking in RPM 5.4.16 in 
Morty is broken.

Backported some changes from upstream and it is working for me now (i.e., 
detecting and
reporting the conflict.)

MV

From: Vuille, Martin (Martin)
Sent: March 09, 2018 20:50
To: yocto@yoctoproject.org
Subject: Two packages installing same file (with different content) to rootfs

Ran into an issue where we have two packages installing different
content for the same file in rootfs. Whichever gets installed last "wins".

I thought there was a check to prevent this. I'm sure I've seen a
warning/error like that in the past.

Is this condition detected? Should it be?

We're using Morty.

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


[yocto] Multiple distros with one bitbake

2018-03-13 Thread Bartłomiej Osiński
Hi, 

With one bitbake command I'm making 2 images: 


1. image-my-initramfs, combined with kernel. I want it to make as small as 
possible. 
2. core-image-minimal, loaded separately 

The problem I have with no. 1 is that some features (most notably cryptsetup) 
force relatively big libraries to be included into image. Yocto doesn't seem to 
have option to force static compilation of those features (or am I wrong?), so 
I have to rely on using smaller glibc. This involves using different distro 
than poky, but on the other hand I'd like my image no. 2 to be left untouched 
(still using poky). Is there a way to achieve this? 

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


[yocto] Integrating Ixxat SocketCAN Drivers in image

2018-03-13 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



Vincent Daanen, PhD - System Integration Director

  New Phone Number +33 (0) 4 76 54 95 22

Orthotaxy
5 avenue du Grand Sablon
38700 La Tronche

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