Re: [yocto] [yocto-docs][PATCH] dev-manual: document CPU features and QB_CPU_KVM
On 04/30/2018 10:25 AM, Scott Rifenbark wrote: Hi Martin, See https://yoctoproject.org/docs/2.5/dev-manual/dev-manual.html#qemu-kvm-cpu-compatibility and let me know if this section works. I took your patch and did some rewriting. Thanks, Scott I like your changes; thanks! On Fri, Apr 27, 2018 at 10:46 AM, Martin Kelly <mailto:mke...@xevo.com>> wrote: As suggested in a recent mail thread by Martin Jansa, there are cases in which QEMU under KVM will crash because of CPU feature incompatibilities between compiled binaries and the host CPU under which qemu is run. Although this is hard to fully escape, we should document the issue to help people work around it. Signed-off-by: Martin Kelly mailto:mke...@xevo.com>> --- documentation/dev-manual/dev-manual-qemu.xml | 22 ++ 1 file changed, 22 insertions(+) diff --git a/documentation/dev-manual/dev-manual-qemu.xml b/documentation/dev-manual/dev-manual-qemu.xml index f4719ebc3..1870a6a8d 100644 --- a/documentation/dev-manual/dev-manual-qemu.xml +++ b/documentation/dev-manual/dev-manual-qemu.xml @@ -343,6 +343,28 @@ + + QEMU CPU Compatiblity under KVM + + + By default, the QEMU build compiles for and targets core2duo (for + 64-bit x86) and pentium2 (for 32-bit x86). These CPUS are chose to + have a broad range of CPU feature compatibility with many commonly + used CPUs, but in some cases, they still support a CPU feature that + your host CPU does not. Although this is not a problem when QEMU + uses software emulation of the feature, it can be when running with + KVM enabled. Specifically, software compiled with a certain CPU + feature will crash when run on a CPU under KVM that does not support + that feature. If this becomes a problem, you can override QEMU's + runtime CPU setting by changing the QB_CPU_KVM + variable in qemuboot.conf in the image deploy + directory. This setting specifies a -cpu option + passed into QEMU in the runqemu script. Running + qemu -cpu help will give a list of supported + CPU types available. + + + QEMU Performance -- 2.11.0 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [yocto-docs][PATCH] dev-manual: document CPU features and QB_CPU_KVM
As suggested in a recent mail thread by Martin Jansa, there are cases in which QEMU under KVM will crash because of CPU feature incompatibilities between compiled binaries and the host CPU under which qemu is run. Although this is hard to fully escape, we should document the issue to help people work around it. Signed-off-by: Martin Kelly --- documentation/dev-manual/dev-manual-qemu.xml | 22 ++ 1 file changed, 22 insertions(+) diff --git a/documentation/dev-manual/dev-manual-qemu.xml b/documentation/dev-manual/dev-manual-qemu.xml index f4719ebc3..1870a6a8d 100644 --- a/documentation/dev-manual/dev-manual-qemu.xml +++ b/documentation/dev-manual/dev-manual-qemu.xml @@ -343,6 +343,28 @@ + +QEMU CPU Compatiblity under KVM + + +By default, the QEMU build compiles for and targets core2duo (for +64-bit x86) and pentium2 (for 32-bit x86). These CPUS are chose to +have a broad range of CPU feature compatibility with many commonly +used CPUs, but in some cases, they still support a CPU feature that +your host CPU does not. Although this is not a problem when QEMU +uses software emulation of the feature, it can be when running with +KVM enabled. Specifically, software compiled with a certain CPU +feature will crash when run on a CPU under KVM that does not support +that feature. If this becomes a problem, you can override QEMU's +runtime CPU setting by changing the QB_CPU_KVM +variable in qemuboot.conf in the image deploy +directory. This setting specifies a -cpu option +passed into QEMU in the runqemu script. Running +qemu -cpu help will give a list of supported +CPU types available. + + + QEMU Performance -- 2.11.0 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] CROPS status?
On 12/18/2017 07:05 AM, Joshua Lock wrote: Hi Martin, On 14/12/17 20:52, Martin Kelly wrote: On 12/13/2017 12:44 PM, Avery, Brian wrote: + joshua. I am no longer working on the YP, but Joshua is looking after CROPS. It is actually a family of containers, so some parts have been updated more recently. -brian Thanks Brian. Joshua, do you know the code status? Is the project still actively being worked on? Are there any related repositories I should be looking at? We have relatively little time for feature development, but we are attempting to keep the container images up-to-date with new distro releases. There are Fedora 27 and Ubuntu 17.10 versions of the containers available on Docker Hub[1]. Thanks, Joshua 1. https://hub.docker.com/r/crops/ OK, thanks for the information! -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] CROPS status?
On 12/13/2017 12:44 PM, Avery, Brian wrote: + joshua. I am no longer working on the YP, but Joshua is looking after CROPS. It is actually a family of containers, so some parts have been updated more recently. -brian Thanks Brian. Joshua, do you know the code status? Is the project still actively being worked on? Are there any related repositories I should be looking at? On 12/13/17, 10:26 AM, "Martin Kelly" wrote: Hi, I recently discovered the CROPS project at https://github.com/crops/crops. It looks like a great idea, but I see it hasn't had a commit since June 23, 2016. Is the project still active? Thanks, Martin -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] CROPS status?
Hi, I recently discovered the CROPS project at https://github.com/crops/crops. It looks like a great idea, but I see it hasn't had a commit since June 23, 2016. Is the project still active? Thanks, Martin -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How should we handle GCC 6 and -isystem /usr/include?
On 04/25/2017 05:44 PM, Khem Raj wrote:
On 4/20/17 5:04 PM, Martin Kelly wrote:
Hi,
After compiling a package with GCC 6, I noticed the following error,
which is a known issue:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129
The problem is caused by adding -isystem /usr/include, which breaks the
GCC 6's #include_next. I see that Khem Raj already removed this for the
nativesdk [1], but it seems we need a similar fix for other packages, as
we are still adding -isystem in meta/conf/bitbake.conf:
[snip]
BUILDSDK_CPPFLAGS = "-isystem${STAGING_INCDIR}"
[snip]
You must be not using master since it has been fixed by
http://git.openembedded.org/openembedded-core/commit/meta/conf/bitbake.conf?id=88ec93d152762aedeaa231d2732e9d4b9843795a
The bug is referenced is actually exactly that commit (just in poky
rather than oe-core); it looks like I mistyped, as I should have said:
[snip]
export BUILD_CPPFLAGS = "-isystem${STAGING_INCDIR_NATIVE}"
[snip]
That said, after further root causing the issue, I found that -isystem
/usr/include was *not* coming from BUILD_CPPFLAGS but instead from QMake
translating -I /usr/include into -isystem /usr/include, as is mentioned
in this Qt bug:
https://bugreports.qt.io/browse/QTBUG-53375
So, AFAICT, what I referenced in bitbake is not really an issue, and the
real problem is related to QMake.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Qt 5.8: do_rootfs: File 'qtdeclarative-plugins' not found
On 04/25/2017 07:41 AM, Malte Thiel wrote:
Hello,
I am trying to compile a Qt 5.8 application using the master branch
of meta-qt5/recipes-qt/qt5/ (For 5.8 support).
Within my recipe I have:
RDEPENDS_${PN} = "libgcc glibc qtbase [...] qtdeclarative"
My recipe (and therefore the application) compiles fine. However, in
do_rootfs I get the following error:
ERROR: my-image-1.0-r0 do_rootfs: Error executing a python function in
exec_python_func() autogenerated:
[...]
Exception: FileNotFoundError: [Errno 2] No such file or directory:
'/home/sec/sdk/build/0101301/tmp/sysroots/sm2-imx6/pkgdata/runtime-reverse/qtdeclarative-plugins'
ERROR: my-image-1.0-r0 do_rootfs: Function failed: license_create_manifest
It's true, there is no file 'qtdeclarative-plugins'.
However, qtdeclarative RPROVIDES qtdeclarative-plugins, so I expect that
this file should be generated somehow?
Any help is appreciated
Hi,
I actually hit this issue as well. I discovered that
qtdeclarative-plugins wasn't being generated because it was empty, and
by default, bitbake won't generate an empty package. You can fix it by
adding:
ALLOW_EMPTY_${PN}-plugins = "1"
to the qtdeclarative_git.bb file. That said, I'm not sure if this is the
right fix, or if there is some other reason why qtdeclarative-plugins is
not being generated.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] How should we handle GCC 6 and -isystem /usr/include?
Hi,
After compiling a package with GCC 6, I noticed the following error,
which is a known issue:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129
The problem is caused by adding -isystem /usr/include, which breaks the
GCC 6's #include_next. I see that Khem Raj already removed this for the
nativesdk [1], but it seems we need a similar fix for other packages, as
we are still adding -isystem in meta/conf/bitbake.conf:
[snip]
BUILDSDK_CPPFLAGS = "-isystem${STAGING_INCDIR}"
[snip]
I experimented with a few options:
- Changing this to "-I${STAGING_INCDIR}". Although this works (and the
poky repo will recompile with it), I believe it will break when a recipe
does -Wall -Werror and hits an error in the standard include files
(-isystem specifically ignores warnings for this reason.)
- Changing this to just "". This breaks at least pbzip2-native, which
can no longer find bzlib.h, since it uses the system g++ to do so and
bzlib-dev is not installed.
I'm guessing the right solution involves passing a --sysroot option to
the native build instead of -isystem so that the builtin gcc/g++
/usr/include will find the right files.
Does this sound right, or do you have other ideas?
Thanks,
Martin
[1] poky 54d06c080393785270313878bc4a15a9915571ba
https://patchwork.openembedded.org/patch/122285/
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Relicensing an Apache-licensed recipe as MIT
On 04/12/2017 09:43 AM, Martin Kelly wrote: On 04/12/2017 03:50 AM, Jussi Kukkonen wrote: On 12 April 2017 at 12:54, Paul Eggleton mailto:paul.eggle...@linux.intel.com>> wrote: On Wednesday, 12 April 2017 7:14:00 PM NZST Jussi Kukkonen wrote: > On 11 April 2017 at 23:52, Martin Kelly mailto:mke...@xevo.com>> wrote: > > I'm thinking about integrating the open-vm-tools recipe from openswitch[1] > > into openembedded (it massively improves the performance of VMWare guests) > > but first I have a question about licensing. The openswitch repository is > > Apache-licensed while the openembedded layers are all MIT licensed. I'm > > not > > a lawyer, but my understanding is that the Apache license is a superset of > > the MIT license (it includes a patent clause that the MIT license lacks), > > and therefore MIT code can be relicensed as Apache but not the other way > > around. > > The license of the layer refers to the licensing of the recipe files > themselves: the source code licenses of the projects the recipes fetch and > build are another thing. As long as the source code license is an open > source one there should be no complaints about integrating into an > openembedded layer. > > To be completely clear: The LICENSE variable in a recipe refers to the > source code license of the project to be built and should be set based on > the licensing info found within the version of source code that we fetch > and build. The recipe files are licensed according to the LICENSE and/or > COPYING files of the layer it is in. > > By the way, a quick search on layers.openembedded.org <http://layers.openembedded.org> reveals this: > http://git.openswitch.net/cgit/openswitch/ops-build/tree/yocto/openswitch/me <http://git.openswitch.net/cgit/openswitch/ops-build/tree/yocto/openswitch/me> > ta-foss-openswitch/recipes-extended/open-vm-tools/open-vm-tools_10.0.5.bb <http://open-vm-tools_10.0.5.bb> > (it seems to think the correct license is GPL). This is muddying the waters somewhat - the LICENSE variable has nothing to do with this. We're only concerned with the license of the recipe itself. Thanks Paul: I was indeed confused and did not understand this was about an existing recipe even though it was clearly explained in the original post. Sorry for the noise. Jussi Right, I should have clarified. The underlying code is LGPLv2/GPLv2, but the recipe file itself is Apache licensed, which is my concern. It sounds like I should ask openswitch for relicensing first. If they say no, we can consider the situation further. OK, Diego Dompe, the recipe's author, is amenable to relicensing, so I will go ahead and do that. Thanks for the help! -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Relicensing an Apache-licensed recipe as MIT
On 04/12/2017 03:50 AM, Jussi Kukkonen wrote: On 12 April 2017 at 12:54, Paul Eggleton mailto:paul.eggle...@linux.intel.com>> wrote: On Wednesday, 12 April 2017 7:14:00 PM NZST Jussi Kukkonen wrote: > On 11 April 2017 at 23:52, Martin Kelly mailto:mke...@xevo.com>> wrote: > > I'm thinking about integrating the open-vm-tools recipe from openswitch[1] > > into openembedded (it massively improves the performance of VMWare guests) > > but first I have a question about licensing. The openswitch repository is > > Apache-licensed while the openembedded layers are all MIT licensed. I'm > > not > > a lawyer, but my understanding is that the Apache license is a superset of > > the MIT license (it includes a patent clause that the MIT license lacks), > > and therefore MIT code can be relicensed as Apache but not the other way > > around. > > The license of the layer refers to the licensing of the recipe files > themselves: the source code licenses of the projects the recipes fetch and > build are another thing. As long as the source code license is an open > source one there should be no complaints about integrating into an > openembedded layer. > > To be completely clear: The LICENSE variable in a recipe refers to the > source code license of the project to be built and should be set based on > the licensing info found within the version of source code that we fetch > and build. The recipe files are licensed according to the LICENSE and/or > COPYING files of the layer it is in. > > By the way, a quick search on layers.openembedded.org <http://layers.openembedded.org> reveals this: > http://git.openswitch.net/cgit/openswitch/ops-build/tree/yocto/openswitch/me <http://git.openswitch.net/cgit/openswitch/ops-build/tree/yocto/openswitch/me> > ta-foss-openswitch/recipes-extended/open-vm-tools/open-vm-tools_10.0.5.bb <http://open-vm-tools_10.0.5.bb> > (it seems to think the correct license is GPL). This is muddying the waters somewhat - the LICENSE variable has nothing to do with this. We're only concerned with the license of the recipe itself. Thanks Paul: I was indeed confused and did not understand this was about an existing recipe even though it was clearly explained in the original post. Sorry for the noise. Jussi Right, I should have clarified. The underlying code is LGPLv2/GPLv2, but the recipe file itself is Apache licensed, which is my concern. It sounds like I should ask openswitch for relicensing first. If they say no, we can consider the situation further. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Relicensing an Apache-licensed recipe as MIT
Hi, I'm thinking about integrating the open-vm-tools recipe from openswitch[1] into openembedded (it massively improves the performance of VMWare guests) but first I have a question about licensing. The openswitch repository is Apache-licensed while the openembedded layers are all MIT licensed. I'm not a lawyer, but my understanding is that the Apache license is a superset of the MIT license (it includes a patent clause that the MIT license lacks), and therefore MIT code can be relicensed as Apache but not the other way around. If that's the case, then there's two options here: (1) - Include this recipe in openembedded with an Apache license, while the rest of the recipes are MIT-licensed. This sounds complicated, messy, and probably not feasible. (2) - Ask openswitch for permission to relicense that one recipe as MIT with attributions. I'm wondering if someone with a better understanding than I have could provide me me advice about the best way to proceed. Thanks, Martin [1]: https://github.com/open-switch/ops-build/tree/master/yocto/openswitch/meta-foss-openswitch/recipes-extended/open-vm-tools -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] runqemu - "Could not initialize SDL(No available video device) - exiting"
I found the source of the issue (SDL must be compiled with X11 support) and sent a patch to OE-core to fix it: https://patchwork.openembedded.org/series/6211 On 04/04/2017 03:41 PM, Martin Kelly wrote: [This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing] Hi, I'm hitting an error on runqemu when I try to build an SDK and image on one machine and run it on another, even when the build machine and qemu-running machine match very closely (both running Debian Jessie on Intel 64-bit hardware). Specifically, I get this error: Could not initialize SDL(No available video device) - exiting Interestingly, I don't get this when I do runqemu on the same machine that built the image and SDK (in fact, it works on either machine, as long as the image/SDK never leave the machine). Now, if I manually copy and paste the runqemu command, but just use the Debian-provided qemu instead of the one from the SDK, then again everything works fine. Note also that libSDL-1.2.so.0 is installed on both systems. At this point I'm pretty stumped. Google says that, in the past, this occurred because of X11 ABI issues: https://bugzilla.yoctoproject.org/show_bug.cgi?id=5040 However, the x11-native version I'm building through 1.6.3, and Debian Jessie provides 1.6.2, so I would guess the ABI is OK between those two versions. In addition, the fact that it works on the same machine that built the SDK and image is strange. Any ideas what might be wrong? Thanks, Martin -- ___ 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] runqemu - "Could not initialize SDL(No available video device) - exiting"
Hi, I'm hitting an error on runqemu when I try to build an SDK and image on one machine and run it on another, even when the build machine and qemu-running machine match very closely (both running Debian Jessie on Intel 64-bit hardware). Specifically, I get this error: Could not initialize SDL(No available video device) - exiting Interestingly, I don't get this when I do runqemu on the same machine that built the image and SDK (in fact, it works on either machine, as long as the image/SDK never leave the machine). Now, if I manually copy and paste the runqemu command, but just use the Debian-provided qemu instead of the one from the SDK, then again everything works fine. Note also that libSDL-1.2.so.0 is installed on both systems. At this point I'm pretty stumped. Google says that, in the past, this occurred because of X11 ABI issues: https://bugzilla.yoctoproject.org/show_bug.cgi?id=5040 However, the x11-native version I'm building through 1.6.3, and Debian Jessie provides 1.6.2, so I would guess the ABI is OK between those two versions. In addition, the fact that it works on the same machine that built the SDK and image is strange. Any ideas what might be wrong? Thanks, Martin -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
