Re: [yocto] LINUX_VERSION issue in recipe

On 4/27/2018 5:34 PM, Andre McCurdy wrote: On Fri, Apr 27, 2018 at 3:44 AM, Damien LEFEVRE wrote: Hi, This must be a stupid basic question. I have the following recipe append: keymaps_1.0.bbappend

Re: [linux-yocto] [yocto-4.12] [standard/*/axxia/base] [PATCH] tools/perf: Include inttypes.h to avoid error in cs-etm.c

On 4/25/2018 10:31 PM, qwang2 wrote: On 2018年04月25日 21:38, Bruce Ashfield wrote: On 04/25/2018 09:39 AM, Daniel Dragomir wrote: | util/cs-etm.c:1264:40: error: expected '}' before 'PRIx64' |    [CS_ETM_MAGIC] = "   Magic number  %"PRIx64"\n", |

[yocto] python & xml2

I am trying to install libxml2 for python2 in my image recipe. Seems like it is being installed in the python3 site packages directory instead of the python2 site packages directory. While looking into this I have become very confused. Is there some documentation on this? Do I need to set

Re: [yocto] LINUX_VERSION issue in recipe

On Fri, Apr 27, 2018 at 3:44 AM, Damien LEFEVRE wrote: > Hi, > > This must be a stupid basic question. I have the following recipe append: > > keymaps_1.0.bbappend > - > FILESEXTRAPATHS_prepend :=

[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

[yocto] [patchtest-oe][PATCH] test_metadata_src_uri.py: Check if files are added

Check if files are added to the patchset and not added to the SRC_URI. This will prevent test_src_uri_left_files from giving a false positive when patches are renamed in the patchset and not renamed in the SRC_URI. Also update the fail message from "Patches not removed from tree" to "Patches not

Re: [yocto] pygtk package in yocto

Do you actually need pygtk, or the gobject-introspection bindings for Python? The latter is what is supported upstream, traditional pygtk was last released in 2011. If you're lucky you actually just need gtk+3 and python-pygobject. If you *really* need PyGTK then you'll have to resurrect the

[yocto] LINUX_VERSION issue in recipe

Hi, This must be a stupid basic question. I have the following recipe append: keymaps_1.0.bbappend - FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" SRC_URI_append = " file://keymaps.service \

[yocto] pygtk package in yocto

Hi Guys, I am using the latest branch of poky and meta-oe . I need pygtk package for one of my application as it's one of the requirement for it to run. Pygtk is supported in Jethro branch. Do I need to switch to Jethro branch for my project or did anyone port pygtk recipe port for the latest

[yocto] nothing provides mono(System.Runtime.Loader)

Hi, I am trying to build core-image-mono with Rocko release of the Yocto and meta-mono and I am getting the following error. ore-image-mono-1.0-r0 do_rootfs  Problem 1: package mono-5.4.1.6-r0.1.armv7ahf_neon requires mono-libs-4.5, but none of the providers can be installed   -

Re: [yocto] Installing a package on the board at runtime

On Fri, Apr 27, 2018 at 5:39 PM, Alan Martinovic wrote: > Hey > >> A more > controlled way of installing packages would be to have > package-management added to your IMAGE_FEATURES [1] to leverage a > fully fledged package manager on the target (like any mainstream >

Re: [yocto] Installing a package on the board at runtime

Hey > A more controlled way of installing packages would be to have package-management added to your IMAGE_FEATURES [1] to leverage a fully fledged package manager on the target (like any mainstream distro). Yeah, I admit I have been ignorantly avoiding this, always thinking that it isn't worth

[yocto] "Waiting for Removable Media" hang

I use Krogoth (released 4/2016) Camelback Mountain BSP, trying to do network boot. Initialization hangs indefinitely with "Waiting for Removable Media". This is a big issue for us, because we need to deal with the diskless situation. It looks like this issue was here some 7-8 years ago. It

Re: [yocto] Installing a package on the board at runtime

Hi Alan, On Fri, Apr 27, 2018 at 1:38 PM, Alan Martinovic wrote: > Hey, > I know there is a method in devtool called devtool deploy-target. > It's a great thing to install a package on the board at runtime. > > Is there something like that available without devtool?

Re: [yocto] yocto Digest, Vol 91, Issue 105

-Original Message- > Date: Fri, 27 Apr 2018 13:38:35 +0200 > From: Alan Martinovic > To: Yocto-mailing-list > Subject: [yocto] Installing a package on the board at runtime > Message-ID: >

Re: [yocto] yocto jethro failed on gettext-native

> Take a look at BIOS settings. I had a board that was overclocking based > on CPU temperature, which failed miserably when you actually used all > the cores. Disable such settings. This has nothing to do with this particular problem. You simply, since you over-clocked CPU, reached very quickly

[yocto] [PATCH V2][meta-mingw] machine-sdk: split out common configuration

Signed-off-by: Ross Burton --- conf/machine-sdk/i686-mingw32.conf | 36 + conf/machine-sdk/include/mingw32-common.inc | 36 + conf/machine-sdk/x86_64-mingw32.conf| 36 + 3

[yocto] [PATCH][meta-mingw 2/2] machine-sdk: set the nativesdk libc to libc-mingw

We need to set this so that the override for nativesdk builds using MinGW don't think they're using glibc. Signed-off-by: Ross Burton --- conf/machine-sdk/include/mingw32-common.inc | 1 + 1 file changed, 1 insertion(+) diff --git

[yocto] [PATCH][meta-mingw 1/2] machine-sdk: split out common configuration

Signed-off-by: Ross Burton --- conf/machine-sdk/i686-mingw32.conf | 36 + conf/machine-sdk/include/mingw32-common.inc | 36 + 2 files changed, 37 insertions(+), 35 deletions(-) create mode 100644

Re: [yocto] yocto jethro failed on gettext-native

On 04/27/2018 02:19 AM, Oliver Graute wrote: > On 26/04/18, Zoran Stojsavljevic wrote: >>> I deleted all the build-imx6ulevk folder and build everything from >>> scratch with only one thread, waited a few hours for compilation and now >>> its working ;) >> >> Still, I am struggling to understand

[yocto] Installing a package on the board at runtime

Hey, I know there is a method in devtool called devtool deploy-target. It's a great thing to install a package on the board at runtime. Is there something like that available without devtool? A digression: Am asking for a non devtool option because it seems like devtool is ignoring the patch

[yocto] [meta-selinux][PATCH] refpolicy: Update to 20180114 release

From: Wenzong Fan Remove patches that included by upstream: - poky-fc-nscd.patch - poky-fc-ftpwho-dir.patch - refpolicy-update-for_systemd.patch - 0005-refpolicy-minimum-init-fix-reboot-with-systemd-as-in.patch Rebase patches: - poky-fc-clock.patch -

Re: [yocto] yocto jethro failed on gettext-native

> Perhaps I will try 18.04 LTS which released yesterday ;) This will be very interesting test. I bet it'll not work 100% (any of use cases, with any number of threads). Native packages moved far beyond Y2015, far beyond YOCTO Jethro release. Zoran ___ On Fri, Apr 27, 2018 at 8:19 AM,

Re: [yocto] PXE Boot NFS not working

Regarding to your question on legacy BIOS. 1. vesamenu.c32 or menu.32 are graphic library to display PXE menu. Normally if you don't provide these files, you will not able to see PXE menu. 2. Use kernel or linux parameter is depend on your GRUB bootloader command. You can try to

Re: [yocto] yocto jethro failed on gettext-native

On 26/04/18, Zoran Stojsavljevic wrote: > > I deleted all the build-imx6ulevk folder and build everything from > > scratch with only one thread, waited a few hours for compilation and now > > its working ;) > > Still, I am struggling to understand why??? What is the requirement > behind this ask?