Re: [yocto] Debugging custom python code in recipes
On 01/11/2019 21:30, Alan Martinović wrote: Cool, thanks. This one seems to be the most up to date from the python debugger wrappers: https://github.com/ionelmc/python-remote-pdb Entirely worth writing a proper class and pushing a layer somewhere. The `shell_wait()` in your bbclass is related to the pdb() functionality? No, it's just a way of making shell tasks pause for inspecting the state of the build tree during a task. I was debugging some nasty packaging failures... Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Debugging custom python code in recipes
Cool, thanks. This one seems to be the most up to date from the python debugger wrappers: https://github.com/ionelmc/python-remote-pdb The `shell_wait()` in your bbclass is related to the pdb() functionality? On Fri, Nov 1, 2019 at 10:14 PM Ross Burton wrote: > > On 01/11/2019 20:44, Alan Martinović wrote: > > Hey, > > there was a question today about options for debugging python scripts in > > yocto. > > I've patched up this PoC for remote debugging. > > FWIW, I've done something similar using bare pdb. > > https://github.com/rossburton/meta-ross/blob/master/classes/pdb.bbclass > > Just call pdb() from Python context. Not as neat as epdb though. > > Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Debugging custom python code in recipes
On 01/11/2019 20:44, Alan Martinović wrote: Hey, there was a question today about options for debugging python scripts in yocto. I've patched up this PoC for remote debugging. FWIW, I've done something similar using bare pdb. https://github.com/rossburton/meta-ross/blob/master/classes/pdb.bbclass Just call pdb() from Python context. Not as neat as epdb though. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Debugging custom python code in recipes
Hey,
there was a question today about options for debugging python scripts in yocto.
I've patched up this PoC for remote debugging.
If someone finds it useful (it should be copy-pastable), feel free to
ping me back.
Am opet to shaping it into a friendlier format and discover potential issues.
```
# epdb is a python debugger which has a capability of attaching to breakpoints
# on running daemons. Install it on the host.
pip3 install epdb
git clone -b zeus git://git.yoctoproject.org/poky.git
cd poky
# Create a example .inc file in a random location
cat > meta/recipes-core/images/python-debug-example.inc << "EOF"
python () {
# Import the epdb installed on the host
import epdb
random_action = 3
# Set the breakpoint.
# This will stop the program and open a channel to connect to the
interactive debugger
epdb.serve()
some_other_action = 5
another_action = 6
}
EOF
# Add the .inc file to an arbitrary image
# Triggering the image build, the python code will be executed
# and the breakpoint reached
cat >> meta/recipes-core/images/core-image-minimal.bb << EOF
require python-debug-example.inc
EOF
source oe-init-build-env
# This will block because of the breakpoint
bitbake core-image-minimal
# Open a new terminal and connect to the debugger
python3 -c "import epdb; epdb.connect()"
# You should see something like...
# (Epdb) l
# 5 random_action = 3
# 6
# 7 # Set the breakpoint.
# 8 # This will stop the program and open a channel to
connect to the interactive debugger
# 9 epdb.serve()
# 10 -> some_other_action = 5
# 11 another_action = 6
# 12 }
#[EOF]
# ... which is the interactive python debugger
```
Be Well,
Alan
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] poky thud: qtscript fails to build with undefined reference to `cti_vm_throw'
On Fri, Nov 1, 2019 at 2:12 AM wrote: Hello, I tried to build a poky SDK with QT5 support (I am using poky thud). Unfortunately this failed while bitbaking qtscript. When executing "bitbake qtscript" directly I get the same error. Here are the IMHO relevant lines of the huge log.do_compile file. I have replaced the long paths by <...> for clarity. -- multiple warnings --- ... warning: 'template class std::auto_ptr' is deprecated [-Wdeprecated-declarations] --- -- warning --- In member function 'allocatePropertyStorageInline', inlined from 'allocatePropertyStorage' at <...>/git/src/3rdparty/javascriptcore/JavaScriptCore/runtime/JSObject.cpp:546:34: <...>/git/src/3rdparty/javascriptcore/JavaScriptCore/runtime/JSObject.h:679:68: warning: argument 1 value '4294967295' exceeds maximum object size 2147483647 [-Walloc-size-larger-than=] PropertyStorage newPropertyStorage = new EncodedJSValue[newSize]; ^ <...>/git/src/3rdparty/javascriptcore/JavaScriptCore/runtime/JSObject.h: In member function 'allocatePropertyStorage': <...>/recipe-sysroot/usr/include/c++/8.2.0/new:122:7: note: in a call to allocation function 'operator new []' declared here void* operator new[](std::size_t) _GLIBCXX_THROW (std::bad_alloc) --- --- error --- <...>/recipe-sysroot-native/usr/bin/i686-poky-linux/../../libexec/i686-poky-linux/gcc/i686-poky-linux/8.2.0/ld: <...>/recipe-sysroot-native/usr/bin/i686-poky-linux/../../libexec/i686-poky-linux/gcc/i686-poky-linux/8.2.0/ld: DWARF error: invalid abstract instance DIE ref /tmp/ccSwzRoN.ltrans0.ltrans.o: in function `ctiVMThrowTrampoline': :(.text+0x1f): undefined reference to `cti_vm_throw' collect2: error: ld returned 1 exit status Makefile:666: recipe for target '../../lib/libQt5Script.so.5.12.2' failed --- Has anyone an idea what could be the problem? perhaps we need to patch binutils/ld with https://patches-gcc.linaro.org/patch/9614/ see https://sourceware.org/bugzilla/show_bug.cgi?id=23425 if you could try it out and report back that would be awesome Thanks for the quick response. I'll give it a try next week, when I am back in the office. Regards Jochen Thanks Jochen -- ___ 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] [zeus] icu-native-64.2-r0 do_configure: configure failed
Thanks Ross, that was a great help! Not sure I would found it... Indeed python3 was installed but not all required elements: sudo apt-get install python3-distutils was my friend. Best regards Arno -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [yocto-2.7, nativesdk-diffutils]: patched-away problem intermittently persists.
Hi all, I have seen the nativesdk-diffutils compilation fail with the exact problem that is supposed to be solved by: file://0001-explicitly-disable-replacing-getopt.patch The build failure which occurs is 100% identical in all its symptoms to what happens if we remove this patch: In file included from ./getopt.h:85:0, from ../../diffutils-3.6/lib/xstrtol.h:22, from ../../diffutils-3.6/lib/xstrtol-error.c:20: ./config.h:2072:25: warning: 'struct rpl_option' declared inside parameter list will not be visible outside of this definition or declaration #define __GETOPT_PREFIX rpl_ ^ ../../diffutils-3.6/lib/getopt-pfx-core.h:38:44: note: in expansion of macro '__ GETOPT_PREFIX' # define __GETOPT_ID(y) __GETOPT_XCONCAT (__GETOPT_PREFIX, y) ^~~ I don't know if it's a problem with the patch, or if somehow it's not getting applied; next time it happens I will have more info. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [wpe-webkit] Optimising imx6 performance for HTML5 using Cog + WPE WebKit
> -Original Message- > From: webkit-wpe [mailto:webkit-wpe-boun...@lists.webkit.org] On Behalf Of > Andy Pont > Sent: woensdag 23 oktober 2019 13:27 > To: meta-freescale Mailing List > Cc: yocto@yoctoproject.org; webkit-...@lists.webkit.org > Subject: [wpe-webkit] Optimising imx6 performance for HTML5 using Cog + > WPE WebKit > Hello, > > Broadening this out to the Freescale and Yocto mailing lists to see if any one > has any answers… > > We are using Cog and WPE Webkit on an i.MX6 Solo based board with a user > interface that is based on HTML5, Javascript and CSS and are having some > issues with fading and other canvas effects. The board is running a Yocto > image with the following in conf/local.conf: > > PREFERRED_PROVIDER_virtual/wpebackend = "wpebackend-rdk" > PACKAGECONFIG_pn-wpebackend-rdk = "imx6" > > PACKAGECONFIG_append_pn-cairo = " glesv2 egl" > PACKAGECONFIG_append_pn-wpewebkit = " 2dcanvas" > > We start the browser with the following command line: > > cog --enable-accelerated-2d-canvas=1 appui/index.html > > Are there any other settings we should be using either in the Yocto build or > when launching Cog as we are finding the CPU usage is >90%? > > Is there a definitive way to show that all of the necessary drivers are loaded > and Cog is making use of the GPU? > > I have tried this with Cog 0.3.0 built with WPE WebKit 2.24.1 and Cog > 0.4.0 built with WPE WebKit 2.26.1 and both give the same dissappointing > results, as does running on the iMX6Q-SDP board I also have here. Problem with 'interface based on HTML5, javascript and CSS', is that it can be done in a thousand ways... Some of them will fall back to hardware, and some of them will need calculation so take CPU time. Without an insight in a code-abstraction, it's impossible to tell what the issue is. https://medium.com/outsystems-experts/how-to-achieve-60-fps-animations-with-css3-db7b98610108 => some hints on how to improve mobile performance https://www.sitepoint.com/introduction-to-hardware-acceleration-css-animations/ => some more hints to leverage functions to hardware But I also don't reach 60fps on imx6 (yet?) Grt, Wouter -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] minicom hangs when Attempting to communicate with ttyUSB1
Hello All, I have GSM module which enumerates as /dev/ttyUSB0 and ttyUSB1. When I try communicating with the module using minicom. The application hangs. As in, I am unable to send an AT command and I am unable to exit minicom. The command that I am using is *minicom -b 115200 -D /dev/ttyUSB1* So to debug the situation I used Raspberrypi buster image and tried the same steps. And I was able to communicate with it. What could be the problem here? I have usbserial module on both the images installed. Am I missing some other packages. Regards, Shravan Singh (239) 243-0838 Blue Sparq, Inc. 928 NE 24th Lane unit 4 and 5. Cape Coral, FL 33993 IMPORTANT: The contents of this email and any attachments are confidential. They are intended for the named recipient(s) only. If you have received this email by mistake, please notify the sender immediately and do not disclose the contents to anyone or make copies thereof. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] visual studio code packages or building instructions?
-Original Message-
From: Ross Burton
Sent: Friday, November 1, 2019 2:04 PM
To: Aaron Solochek ; yocto@yoctoproject.org
Subject: Re: [yocto] visual studio code packages or building instructions?
On 01/11/2019 17:51, Aaron Solochek wrote:
> Well I grabbed the .deb that one of those links mentioned and converted it to
> an rpm, but of course there are a ton of unmet dependencies, so I might have
> to build it anyway.
>
> I found these instructions for building it, which are pinned to an
> older version (which is probably fine)
>
> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Ffuturejones%2Fcode-oss-aarch64data=01%7C01%7Caaron.soloc
> hek%40sri.com%7C660e9bc6cada46f92d8608d75ef5d038%7C40779d3379c44626b8b
> f140c4d5e9075%7C1sdata=CLhgG4mZZ2EUuiJlJ5Ebqc3xApqspO4RxMvkaEJZx4
> s%3Dreserved=0
>
> I have gotten most of the dependencies built with bitbake, except for the
> x11 stuff:
>
> ERROR: Nothing RPROVIDES 'packagegroup-core-x11' (but
> /home/aarons/sri/bullitt/nxp/imx-yocto-bsp/sources/meta-fsl-bsp-releas
> e/imx/meta-sdk/dynamic-layers/qt5-layer/recipes-fsl/images/fsl-image-q
> t5-validation-imx.bb RDEPENDS on or otherwise requires it)
> packagegroup-core-x11 was skipped: missing required distro feature
> 'x11' (not in DISTRO_FEATURES)
> NOTE: Runtime target 'packagegroup-core-x11' is unbuildable, removing...
> Missing or unbuildable dependency chain was: ['packagegroup-core-x11']
> ERROR: Required build target 'fsl-image-qt5-validation-imx' has no buildable
> providers.
> Missing or unbuildable dependency chain was:
> ['fsl-image-qt5-validation-imx', 'packagegroup-core-x11']
>
> But this is my local.conf:
>
> MACHINE ??= 'imx8mqevk'
> DISTRO ?= 'fsl-imx-wayland'
> PACKAGE_CLASSES ?= "package_rpm"
> EXTRA_IMAGE_FEATURES ?= "debug-tweaks"
> USER_CLASSES ?= "buildstats image-mklibs image-prelink"
> PATCHRESOLVE = "noop"
> BB_DISKMON_DIRS ??= "\
> STOPTASKS,${TMPDIR},1G,100K \
> STOPTASKS,${DL_DIR},1G,100K \
> STOPTASKS,${SSTATE_DIR},1G,100K \
> STOPTASKS,/tmp,100M,100K \
> ABORT,${TMPDIR},100M,1K \
> ABORT,${DL_DIR},100M,1K \
> ABORT,${SSTATE_DIR},100M,1K \
> ABORT,/tmp,10M,1K"
> PACKAGECONFIG_append_pn-qemu-native = " sdl"
> PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl"
> CONF_VERSION = "1"
> #IMAGE_FEATURES_append = " package-management tools-sdk x11-base x11"
> IMAGE_FEATURES += "package-management"
> IMAGE_FEATURES += "tools-sdk"
> IMAGE_FEATURES += "x11-base"
> IMAGE_FEATURES += "x11"
>
>
> As you can see, I tried adding x11 both using IMAGE_FEATURES += as
> well as IMAGE_FEATURES_append (where I would then comment out the += lines)
> Why is x11 never getting added to the DISTRO_FEATURES? I also tried putting
> x11 in DISTRO_FEATURES and DISTRO_FEATURES_append.
>
> What is the correct thing here?
Adding x11 to IMAGE_FEATURES doesn't achieve anything, as x11 isn't an
IMAGE_FEATURE. It's a DISTRO_FEATURE.
DISTRO ?= 'fsl-imx-wayland'
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FFreescale%2Fmeta-freescale-distro%2Fblob%2Fmaster%2Fconf%2Fdistro%2Ffsl-wayland.confdata=01%7C01%7Caaron.solochek%40sri.com%7C660e9bc6cada46f92d8608d75ef5d038%7C40779d3379c44626b8bf140c4d5e9075%7C1sdata=i7DpsY90tCm4VJheO3d0T%2BZqFh8g7ZwBXpx7XS3xoDE%3Dreserved=0
says that this explicitly does DISTRO_FEATURES_remove = "x11" so you can't add
it back.
I suggest you use a DISTRO that supports X11.
Oh, duh. I need fsl-imx-xwayland.
Thank you!
-Aaron
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] visual studio code packages or building instructions?
On Fri, Nov 1, 2019 at 6:51 PM Aaron Solochek wrote:
>
> Well I grabbed the .deb that one of those links mentioned and converted it to
> an rpm, but of course there are a ton of unmet dependencies, so I might have
> to build it anyway.
>
> I found these instructions for building it, which are pinned to an older
> version (which is probably fine)
>
> https://github.com/futurejones/code-oss-aarch64
>
> I have gotten most of the dependencies built with bitbake, except for the
> x11 stuff:
>
> ERROR: Nothing RPROVIDES 'packagegroup-core-x11' (but
> /home/aarons/sri/bullitt/nxp/imx-yocto-bsp/sources/meta-fsl-bsp-release/imx/meta-sdk/dynamic-layers/qt5-layer/recipes-fsl/images/fsl-image-qt5-validation-imx.bb
> RDEPENDS on or otherwise requires it)
> packagegroup-core-x11 was skipped: missing required distro feature 'x11' (not
> in DISTRO_FEATURES)
> NOTE: Runtime target 'packagegroup-core-x11' is unbuildable, removing...
> Missing or unbuildable dependency chain was: ['packagegroup-core-x11']
> ERROR: Required build target 'fsl-image-qt5-validation-imx' has no buildable
> providers.
> Missing or unbuildable dependency chain was: ['fsl-image-qt5-validation-imx',
> 'packagegroup-core-x11']
>
> But this is my local.conf:
>
> MACHINE ??= 'imx8mqevk'
> DISTRO ?= 'fsl-imx-wayland'
The name of the distro most likely means that this distro is doing
DISTRO_FEATURES_remove = "x11"
which would result in the 'error' you are seeing. You should use a
distro which is compatible with X11 instead.
> PACKAGE_CLASSES ?= "package_rpm"
> EXTRA_IMAGE_FEATURES ?= "debug-tweaks"
> USER_CLASSES ?= "buildstats image-mklibs image-prelink"
> PATCHRESOLVE = "noop"
> BB_DISKMON_DIRS ??= "\
> STOPTASKS,${TMPDIR},1G,100K \
> STOPTASKS,${DL_DIR},1G,100K \
> STOPTASKS,${SSTATE_DIR},1G,100K \
> STOPTASKS,/tmp,100M,100K \
> ABORT,${TMPDIR},100M,1K \
> ABORT,${DL_DIR},100M,1K \
> ABORT,${SSTATE_DIR},100M,1K \
> ABORT,/tmp,10M,1K"
> PACKAGECONFIG_append_pn-qemu-native = " sdl"
> PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl"
> CONF_VERSION = "1"
> #IMAGE_FEATURES_append = " package-management tools-sdk x11-base x11"
> IMAGE_FEATURES += "package-management"
> IMAGE_FEATURES += "tools-sdk"
> IMAGE_FEATURES += "x11-base"
> IMAGE_FEATURES += "x11"
it fails because x11 is disable in DISTRO_FEATURES, not IMAGE_FEATURES.
>
>
> As you can see, I tried adding x11 both using IMAGE_FEATURES += as well as
> IMAGE_FEATURES_append (where I would then comment out the += lines)
> Why is x11 never getting added to the DISTRO_FEATURES? I also tried putting
> x11 in DISTRO_FEATURES and DISTRO_FEATURES_append.
_remove can't be un-done.
>
> What is the correct thing here?
>
> I also installed yarn according to those instructions, which worked (it said
> it was successfully installed) however when I tried to use it I got an error
> about not finding gulp:
>
> # yarn watch
> yarn run v1.19.1
> $ gulp watch --max_old_space_size=4095
> /bin/sh: gulp: command not found
> error Command failed with exit code 127.
>
> I don't know anything about yarn. Is gulp another package I need to install,
> or should it be part of yarn?
>
> Thank you.
>
> -Aaron
>
> -Original Message-
> From: Ross Burton
> Sent: Friday, November 1, 2019 12:52 PM
> To: Aaron Solochek ; yocto@yoctoproject.org
> Subject: Re: [yocto] visual studio code packages or building instructions?
>
> On 01/11/2019 16:35, Aaron Solochek wrote:
> > I would like to get visual studio code on my NXP i.MX8. If someone is
> > aware of a aarch64 rpm of it, that would be the easiest.
> > Alternatively, if anyone knows how to build it using bitbake, I can build
> > it myself.
>
> Well Microsoft only make x86 binaries available:
>
> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcode.visualstudio.com%2F%23alt-downloadsdata=01%7C01%7Caaron.solochek%40sri.com%7Ca9ecc8ecbf4e4aeb6bf208d75eebd148%7C40779d3379c44626b8bf140c4d5e9075%7C1sdata=mSWDKRoSwEfy2SiGAgOdcKZvcrvofVPqriDnu5Pd3bI%3Dreserved=0
>
> So you'll have to follow the instructions at
> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoft%2Fvscode%2Fwiki%2FHow-to-Contribute%23build-and-rundata=01%7C01%7Caaron.solochek%40sri.com%7Ca9ecc8ecbf4e4aeb6bf208d75eebd148%7C40779d3379c44626b8bf140c4d5e9075%7C1sdata=3WHuWNu9ngP%2Fbymit1UgnuBawO1b123F1LdwTuHot0U%3Dreserved=0
>
> They use Yarn, so you'll have to package that first.
>
> Comments like
> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fvscode%2Fissues%2F6442%23issuecomment-509605292data=01%7C01%7Caaron.solochek%40sri.com%7Ca9ecc8ecbf4e4aeb6bf208d75eebd148%7C40779d3379c44626b8bf140c4d5e9075%7C1sdata=F0XX9b%2FADWjPJbeis%2FgIlyRunHbb4zpj6Mw3ac1Cs%2Fw%3Dreserved=0
> on the bug asking for RPi support isn't exactly encouraging though.
>
> Ross
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
>
Re: [yocto] visual studio code packages or building instructions?
On 01/11/2019 17:51, Aaron Solochek wrote:
Well I grabbed the .deb that one of those links mentioned and converted it to
an rpm, but of course there are a ton of unmet dependencies, so I might have to
build it anyway.
I found these instructions for building it, which are pinned to an older
version (which is probably fine)
https://github.com/futurejones/code-oss-aarch64
I have gotten most of the dependencies built with bitbake, except for the x11
stuff:
ERROR: Nothing RPROVIDES 'packagegroup-core-x11' (but
/home/aarons/sri/bullitt/nxp/imx-yocto-bsp/sources/meta-fsl-bsp-release/imx/meta-sdk/dynamic-layers/qt5-layer/recipes-fsl/images/fsl-image-qt5-validation-imx.bb
RDEPENDS on or otherwise requires it)
packagegroup-core-x11 was skipped: missing required distro feature 'x11' (not
in DISTRO_FEATURES)
NOTE: Runtime target 'packagegroup-core-x11' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['packagegroup-core-x11']
ERROR: Required build target 'fsl-image-qt5-validation-imx' has no buildable
providers.
Missing or unbuildable dependency chain was: ['fsl-image-qt5-validation-imx',
'packagegroup-core-x11']
But this is my local.conf:
MACHINE ??= 'imx8mqevk'
DISTRO ?= 'fsl-imx-wayland'
PACKAGE_CLASSES ?= "package_rpm"
EXTRA_IMAGE_FEATURES ?= "debug-tweaks"
USER_CLASSES ?= "buildstats image-mklibs image-prelink"
PATCHRESOLVE = "noop"
BB_DISKMON_DIRS ??= "\
STOPTASKS,${TMPDIR},1G,100K \
STOPTASKS,${DL_DIR},1G,100K \
STOPTASKS,${SSTATE_DIR},1G,100K \
STOPTASKS,/tmp,100M,100K \
ABORT,${TMPDIR},100M,1K \
ABORT,${DL_DIR},100M,1K \
ABORT,${SSTATE_DIR},100M,1K \
ABORT,/tmp,10M,1K"
PACKAGECONFIG_append_pn-qemu-native = " sdl"
PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl"
CONF_VERSION = "1"
#IMAGE_FEATURES_append = " package-management tools-sdk x11-base x11"
IMAGE_FEATURES += "package-management"
IMAGE_FEATURES += "tools-sdk"
IMAGE_FEATURES += "x11-base"
IMAGE_FEATURES += "x11"
As you can see, I tried adding x11 both using IMAGE_FEATURES += as well as
IMAGE_FEATURES_append (where I would then comment out the += lines)
Why is x11 never getting added to the DISTRO_FEATURES? I also tried putting x11
in DISTRO_FEATURES and DISTRO_FEATURES_append.
What is the correct thing here?
Adding x11 to IMAGE_FEATURES doesn't achieve anything, as x11 isn't an
IMAGE_FEATURE. It's a DISTRO_FEATURE.
DISTRO ?= 'fsl-imx-wayland'
https://github.com/Freescale/meta-freescale-distro/blob/master/conf/distro/fsl-wayland.conf
says that this explicitly does DISTRO_FEATURES_remove = "x11" so you
can't add it back.
I suggest you use a DISTRO that supports X11.
Ross
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] visual studio code packages or building instructions?
Well I grabbed the .deb that one of those links mentioned and converted it to
an rpm, but of course there are a ton of unmet dependencies, so I might have to
build it anyway.
I found these instructions for building it, which are pinned to an older
version (which is probably fine)
https://github.com/futurejones/code-oss-aarch64
I have gotten most of the dependencies built with bitbake, except for the x11
stuff:
ERROR: Nothing RPROVIDES 'packagegroup-core-x11' (but
/home/aarons/sri/bullitt/nxp/imx-yocto-bsp/sources/meta-fsl-bsp-release/imx/meta-sdk/dynamic-layers/qt5-layer/recipes-fsl/images/fsl-image-qt5-validation-imx.bb
RDEPENDS on or otherwise requires it)
packagegroup-core-x11 was skipped: missing required distro feature 'x11' (not
in DISTRO_FEATURES)
NOTE: Runtime target 'packagegroup-core-x11' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['packagegroup-core-x11']
ERROR: Required build target 'fsl-image-qt5-validation-imx' has no buildable
providers.
Missing or unbuildable dependency chain was: ['fsl-image-qt5-validation-imx',
'packagegroup-core-x11']
But this is my local.conf:
MACHINE ??= 'imx8mqevk'
DISTRO ?= 'fsl-imx-wayland'
PACKAGE_CLASSES ?= "package_rpm"
EXTRA_IMAGE_FEATURES ?= "debug-tweaks"
USER_CLASSES ?= "buildstats image-mklibs image-prelink"
PATCHRESOLVE = "noop"
BB_DISKMON_DIRS ??= "\
STOPTASKS,${TMPDIR},1G,100K \
STOPTASKS,${DL_DIR},1G,100K \
STOPTASKS,${SSTATE_DIR},1G,100K \
STOPTASKS,/tmp,100M,100K \
ABORT,${TMPDIR},100M,1K \
ABORT,${DL_DIR},100M,1K \
ABORT,${SSTATE_DIR},100M,1K \
ABORT,/tmp,10M,1K"
PACKAGECONFIG_append_pn-qemu-native = " sdl"
PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl"
CONF_VERSION = "1"
#IMAGE_FEATURES_append = " package-management tools-sdk x11-base x11"
IMAGE_FEATURES += "package-management"
IMAGE_FEATURES += "tools-sdk"
IMAGE_FEATURES += "x11-base"
IMAGE_FEATURES += "x11"
As you can see, I tried adding x11 both using IMAGE_FEATURES += as well as
IMAGE_FEATURES_append (where I would then comment out the += lines)
Why is x11 never getting added to the DISTRO_FEATURES? I also tried putting x11
in DISTRO_FEATURES and DISTRO_FEATURES_append.
What is the correct thing here?
I also installed yarn according to those instructions, which worked (it said it
was successfully installed) however when I tried to use it I got an error about
not finding gulp:
# yarn watch
yarn run v1.19.1
$ gulp watch --max_old_space_size=4095
/bin/sh: gulp: command not found
error Command failed with exit code 127.
I don't know anything about yarn. Is gulp another package I need to install, or
should it be part of yarn?
Thank you.
-Aaron
-Original Message-
From: Ross Burton
Sent: Friday, November 1, 2019 12:52 PM
To: Aaron Solochek ; yocto@yoctoproject.org
Subject: Re: [yocto] visual studio code packages or building instructions?
On 01/11/2019 16:35, Aaron Solochek wrote:
> I would like to get visual studio code on my NXP i.MX8. If someone is
> aware of a aarch64 rpm of it, that would be the easiest.
> Alternatively, if anyone knows how to build it using bitbake, I can build it
> myself.
Well Microsoft only make x86 binaries available:
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcode.visualstudio.com%2F%23alt-downloadsdata=01%7C01%7Caaron.solochek%40sri.com%7Ca9ecc8ecbf4e4aeb6bf208d75eebd148%7C40779d3379c44626b8bf140c4d5e9075%7C1sdata=mSWDKRoSwEfy2SiGAgOdcKZvcrvofVPqriDnu5Pd3bI%3Dreserved=0
So you'll have to follow the instructions at
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoft%2Fvscode%2Fwiki%2FHow-to-Contribute%23build-and-rundata=01%7C01%7Caaron.solochek%40sri.com%7Ca9ecc8ecbf4e4aeb6bf208d75eebd148%7C40779d3379c44626b8bf140c4d5e9075%7C1sdata=3WHuWNu9ngP%2Fbymit1UgnuBawO1b123F1LdwTuHot0U%3Dreserved=0
They use Yarn, so you'll have to package that first.
Comments like
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fvscode%2Fissues%2F6442%23issuecomment-509605292data=01%7C01%7Caaron.solochek%40sri.com%7Ca9ecc8ecbf4e4aeb6bf208d75eebd148%7C40779d3379c44626b8bf140c4d5e9075%7C1sdata=F0XX9b%2FADWjPJbeis%2FgIlyRunHbb4zpj6Mw3ac1Cs%2Fw%3Dreserved=0
on the bug asking for RPi support isn't exactly encouraging though.
Ross
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] poky thud: qtscript fails to build with undefined reference to `cti_vm_throw'
On Fri, Nov 1, 2019 at 2:12 AM wrote: > > Hello, > > I tried to build a poky SDK with QT5 support (I am using poky thud). > Unfortunately this failed while bitbaking qtscript. > When executing "bitbake qtscript" directly I get the same error. > > Here are the IMHO relevant lines of the huge log.do_compile file. > I have replaced the long paths by <...> for clarity. > > -- multiple warnings --- > ... warning: 'template class std::auto_ptr' is deprecated > [-Wdeprecated-declarations] > --- > > -- warning --- > In member function 'allocatePropertyStorageInline', > inlined from 'allocatePropertyStorage' at > <...>/git/src/3rdparty/javascriptcore/JavaScriptCore/runtime/JSObject.cpp:546:34: > <...>/git/src/3rdparty/javascriptcore/JavaScriptCore/runtime/JSObject.h:679:68: > warning: argument 1 value '4294967295' exceeds maximum object size > 2147483647 [-Walloc-size-larger-than=] > PropertyStorage newPropertyStorage = new EncodedJSValue[newSize]; > ^ > <...>/git/src/3rdparty/javascriptcore/JavaScriptCore/runtime/JSObject.h: In > member function 'allocatePropertyStorage': > <...>/recipe-sysroot/usr/include/c++/8.2.0/new:122:7: note: in a call to > allocation function 'operator new []' declared here > void* operator new[](std::size_t) _GLIBCXX_THROW (std::bad_alloc) > --- > > --- error --- > <...>/recipe-sysroot-native/usr/bin/i686-poky-linux/../../libexec/i686-poky-linux/gcc/i686-poky-linux/8.2.0/ld: > > <...>/recipe-sysroot-native/usr/bin/i686-poky-linux/../../libexec/i686-poky-linux/gcc/i686-poky-linux/8.2.0/ld: > DWARF error: invalid abstract instance DIE ref > /tmp/ccSwzRoN.ltrans0.ltrans.o: in function `ctiVMThrowTrampoline': > :(.text+0x1f): undefined reference to `cti_vm_throw' > collect2: error: ld returned 1 exit status > Makefile:666: recipe for target '../../lib/libQt5Script.so.5.12.2' failed > --- > > Has anyone an idea what could be the problem? > perhaps we need to patch binutils/ld with https://patches-gcc.linaro.org/patch/9614/ see https://sourceware.org/bugzilla/show_bug.cgi?id=23425 if you could try it out and report back that would be awesome > Thanks > Jochen > -- > ___ > 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-raspberrypi] poky linux build fails if ARM erratum mfix linker switch is specified
On Fri, Nov 1, 2019 at 1:28 AM Andrei Gherzan wrote: > > Hi Steve, > > On 01/11/2019 05:32, Steve Pavao wrote: > > poky linux build fails when ARM erratum mfix linker switch is specified > > in local.conf: > > > > TARGET_LD_ARCH_append += " -mfix-cortex-a53-843419” > > > > causes build failure. > > > > Please advise how to use this switch successfully. I am synced current > > in master branch in all layers as of today. The switch causes libtool > > link to fail due to missing libbz2.so. If I don’t specify the switch, > > the build completes without errors. > > > > It is important to be able to build poky linux with this switch to avoid > > certain crash conditions as described in the ARM errata document. > > I haven't tried this erratum fix. It is indeed implemented at the > linker's lever. It's curious though to see the bz2 dependency. Can you > share the specific error? I assume you are doing this on RPi3. > this will impact rpi3 in 64bit mode, don't think 32bit needs this. I think its best to add this option in raspberrypi3-64.conf perhaps via TUNE_CCARGS > -- > Andrei Gherzan > -- > ___ > 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] visual studio code packages or building instructions?
On 01/11/2019 16:35, Aaron Solochek wrote: I would like to get visual studio code on my NXP i.MX8. If someone is aware of a aarch64 rpm of it, that would be the easiest. Alternatively, if anyone knows how to build it using bitbake, I can build it myself. Well Microsoft only make x86 binaries available: https://code.visualstudio.com/#alt-downloads So you'll have to follow the instructions at https://github.com/Microsoft/vscode/wiki/How-to-Contribute#build-and-run They use Yarn, so you'll have to package that first. Comments like https://github.com/microsoft/vscode/issues/6442#issuecomment-509605292 on the bug asking for RPi support isn't exactly encouraging though. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] visual studio code packages or building instructions?
On Fri, Nov 1, 2019 at 9:37 AM Aaron Solochek wrote: > > I would like to get visual studio code on my NXP i.MX8. If someone is > aware of a aarch64 rpm of it, that would be the easiest. Alternatively, > if anyone knows how to build it using bitbake, I can build it myself. > I dont think we have recipe for it yet but you might want to look into https://code.headmelted.com/ > Thank you. > > -Aaron > -- > ___ > 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] visual studio code packages or building instructions?
I would like to get visual studio code on my NXP i.MX8. If someone is aware of a aarch64 rpm of it, that would be the easiest. Alternatively, if anyone knows how to build it using bitbake, I can build it myself. Thank you. -Aaron -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-qt5] How to contribute patches for qtwebengine in meta-qt5?
This patch is already included in 5.13.2 upgrade (ready in zeus-next and master-next branches), so you don't need to do anything. Otherwise like Khem says, submit the change for meta-qt5 repository like any other layer. The meta-qt5/qt* repositories are used to maintain the patches, but usually only me is updating them to keep in sync with meta-qt5 and then syncing from them to meta-qt5 with git format-patch --no-numbered --no-signature when doing bigger rebase like when upgrading to newer Qt version. Regards, On Fri, Nov 1, 2019 at 11:02 AM Tanu Kaskinen wrote: > Hi all! > > The meta-qt5 readme says that contributions should be made by forking > the meta-qt5 repository on GitHub, but when I look at the qtwebengine > recipe, it looks like patches are pulled from > https://github.com/meta-qt5/qtwebengine-chromium, and that repository > looks like the patches are kept in a particular order so adding a patch > at the top is perhaps not what I should do. > > It's not clear to me how I should submit a patch in this case. The > patch in question would be a simple backport of this upstream commit: > > https://codereview.qt-project.org/gitweb?p=qt/qtwebengine-chromium.git;a=commitdiff;h=b84e8682b312fb16b16ffb9591415067ceae69f8 > > It's needed for not breaking qtwebengine when upgrading PulseAudio to > 13.0. > > -- > Tanu > > https://www.patreon.com/tanuk > https://liberapay.com/tanuk > > -- > ___ > 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-selinux] zeus branch creation
[[yocto] [meta-selinux] zeus branch creation] On 19.11.01 (Fri 14:02) Vincent Prince wrote: > Hi team, > > Would it be possible to create zeus branch for meta-selinux layer? Yes, for sure. Thanks for the reminder. -- -Joe MacDonald. Linux Architect | Mentor® A Siemens Business :wq signature.asc Description: PGP signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-qt5] How to contribute patches for qtwebengine in meta-qt5?
On Fri, Nov 1, 2019 at 3:02 AM Tanu Kaskinen wrote: > Hi all! > > The meta-qt5 readme says that contributions should be made by forking > the meta-qt5 repository on GitHub, but when I look at the qtwebengine > recipe, it looks like patches are pulled from > https://github.com/meta-qt5/qtwebengine-chromium, and that repository > looks like the patches are kept in a particular order so adding a patch > at the top is perhaps not what I should do. > Like you would do for any other layer is fine Better if you can maintain the patch ordering > > It's not clear to me how I should submit a patch in this case. The > patch in question would be a simple backport of this upstream commit: > > https://codereview.qt-project.org/gitweb?p=qt/qtwebengine-chromium.git;a=commitdiff;h=b84e8682b312fb16b16ffb9591415067ceae69f8 > > It's needed for not breaking qtwebengine when upgrading PulseAudio to > 13.0. > > -- > Tanu > > https://www.patreon.com/tanuk > https://liberapay.com/tanuk > > -- > ___ > 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] [meta-selinux] zeus branch creation
Hi team, Would it be possible to create zeus branch for meta-selinux layer? Kind regards, Vincent -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-qt5] How to contribute patches for qtwebengine in meta-qt5?
Hi all! The meta-qt5 readme says that contributions should be made by forking the meta-qt5 repository on GitHub, but when I look at the qtwebengine recipe, it looks like patches are pulled from https://github.com/meta-qt5/qtwebengine-chromium, and that repository looks like the patches are kept in a particular order so adding a patch at the top is perhaps not what I should do. It's not clear to me how I should submit a patch in this case. The patch in question would be a simple backport of this upstream commit: https://codereview.qt-project.org/gitweb?p=qt/qtwebengine-chromium.git;a=commitdiff;h=b84e8682b312fb16b16ffb9591415067ceae69f8 It's needed for not breaking qtwebengine when upgrading PulseAudio to 13.0. -- Tanu https://www.patreon.com/tanuk https://liberapay.com/tanuk -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [linux-yocto] [kernel-cache yocto-5.2/master] [PATCH] ti-am335x: enable GCC -O2 optimization
On Thu, Oct 31, 2019 at 11:12 PM He Zhe wrote: > > Hi Bruce, > > This now happens on qemuarmv5 and possibly on all arm arches. > > standard.scc -> arm.scc -> arm.cfg -> CONFIG_CC_OPTIMIZE_FOR_SIZE=y > > It hangs the whole system. > But turning off CONFIG_CC_OPTIMIZE_FOR_SIZE would affect all arches. > > What do you think? It used to be the opposite. The boards only booted with this enabled. So my worry about changing it globally is that I fix some boards, and break others. We can always just change the setting in the BSP .cfg's that we can prove they build and boot. Bruce > > Thanks, > Zhe > > > On 10/30/19 8:25 AM, Bruce Ashfield wrote: > > merged. > > > > We should also either have a plan to figure out the root cause > > of this, or we should patch the Kconfig to be broken if enabled > > .. that way we'll prevent others from turning it on by mistake. > > > > > > Bruce > > > > > > In message: [linux-yocto] [kernel-cache yocto-5.2/master] [PATCH] > > ti-am335x: enable GCC -O2 optimization > > on 29/10/2019 Jun Miao wrote: > > > >> Ti-am335x bsp includes the standard.scc file, which will set > >> CONFIG_CC_OPTIMIZE_FOR_SIZE=y. > >> As a result, the system boot hangs like below in v5.4.0-rc4 kernel version: > >> When we enable CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE for -O2 Optimization > >> level, > >> the boot succeeds. > >> > >> boot log: > >> systemd[1]: Set hostname to . > >> systemd[1]: Failed to open netlink: Operation not permitted > >> systemd-fstab-generator[120]: Failed to write unit file -.mount: Bad > >> address > >> systemd-fstab-generator[120]: Failed to write unit file > >> var-volatile.mount: Bad address > >> ... ... > >> systemd[1]: Failed to start device monitor: Bad address > >> systemd[1]: SO_PASSCRED failed: Bad address > >> [!!] Failed to start up manager. > >> systemd[1]: Freezing execution. > >> > >> Signed-off-by: Jun Miao > >> --- > >> bsp/ti-am335x/ti-am335x.cfg | 2 ++ > >> 1 file changed, 2 insertions(+) > >> > >> diff --git a/bsp/ti-am335x/ti-am335x.cfg b/bsp/ti-am335x/ti-am335x.cfg > >> index 71884fd7..190cb876 100644 > >> --- a/bsp/ti-am335x/ti-am335x.cfg > >> +++ b/bsp/ti-am335x/ti-am335x.cfg > >> @@ -258,3 +258,5 @@ CONFIG_OMAP_CONTROL_PHY=y > >> > >> CONFIG_TI_PIPE3=y > >> CONFIG_ARM_PMU=y > >> + > >> +CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y > >> -- > >> 2.17.1 > >> > -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[yocto] poky thud: qtscript fails to build with undefined reference to `cti_vm_throw'
Hello, I tried to build a poky SDK with QT5 support (I am using poky thud). Unfortunately this failed while bitbaking qtscript. When executing "bitbake qtscript" directly I get the same error. Here are the IMHO relevant lines of the huge log.do_compile file. I have replaced the long paths by <...> for clarity. -- multiple warnings --- ... warning: 'template class std::auto_ptr' is deprecated [-Wdeprecated-declarations] --- -- warning --- In member function 'allocatePropertyStorageInline', inlined from 'allocatePropertyStorage' at <...>/git/src/3rdparty/javascriptcore/JavaScriptCore/runtime/JSObject.cpp:546:34: <...>/git/src/3rdparty/javascriptcore/JavaScriptCore/runtime/JSObject.h:679:68: warning: argument 1 value '4294967295' exceeds maximum object size 2147483647 [-Walloc-size-larger-than=] PropertyStorage newPropertyStorage = new EncodedJSValue[newSize]; ^ <...>/git/src/3rdparty/javascriptcore/JavaScriptCore/runtime/JSObject.h: In member function 'allocatePropertyStorage': <...>/recipe-sysroot/usr/include/c++/8.2.0/new:122:7: note: in a call to allocation function 'operator new []' declared here void* operator new[](std::size_t) _GLIBCXX_THROW (std::bad_alloc) --- --- error --- <...>/recipe-sysroot-native/usr/bin/i686-poky-linux/../../libexec/i686-poky-linux/gcc/i686-poky-linux/8.2.0/ld: <...>/recipe-sysroot-native/usr/bin/i686-poky-linux/../../libexec/i686-poky-linux/gcc/i686-poky-linux/8.2.0/ld: DWARF error: invalid abstract instance DIE ref /tmp/ccSwzRoN.ltrans0.ltrans.o: in function `ctiVMThrowTrampoline': :(.text+0x1f): undefined reference to `cti_vm_throw' collect2: error: ld returned 1 exit status Makefile:666: recipe for target '../../lib/libQt5Script.so.5.12.2' failed --- Has anyone an idea what could be the problem? Thanks Jochen -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] poky linux build fails if ARM erratum mfix linker switch is specified
Hi Steve, On 01/11/2019 05:32, Steve Pavao wrote: poky linux build fails when ARM erratum mfix linker switch is specified in local.conf: TARGET_LD_ARCH_append += " -mfix-cortex-a53-843419” causes build failure. Please advise how to use this switch successfully. I am synced current in master branch in all layers as of today. The switch causes libtool link to fail due to missing libbz2.so. If I don’t specify the switch, the build completes without errors. It is important to be able to build poky linux with this switch to avoid certain crash conditions as described in the ARM errata document. I haven't tried this erratum fix. It is indeed implemented at the linker's lever. It's curious though to see the bz2 dependency. Can you share the specific error? I assume you are doing this on RPi3. -- Andrei Gherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
