Re: [linux-yocto] [kernel v5.2/standard/xlnx-soc][PATCH 0/1] sound: soc: xilinx: give a name to stream_name in xilinx_dp_dai_links
On Mon, Nov 11, 2019 at 5:30 AM wrote: > > From: Quanyang Wang > > Hi Bruce & Michal, > > When running "aplay -l" in zcu102 board, there will be a "(null)" in output: > root@xilinx-zynqmp:~# aplay -l > List of PLAYBACK Hardware Devices > card 0: monitor [DisplayPort monitor], device 0: (null) > xilinx-dp-snd-codec-dai-0 [(null) xilinx-dp-snd-codec-dai-0] > Subdevices: 1/1 > Subdevice #0: subdevice #0 > card 0: monitor [DisplayPort monitor], device 1: (null) > xilinx-dp-snd-codec-dai-1 [(null) xilinx-dp-snd-codec-dai-1] > Subdevices: 1/1 > Subdevice #0: subdevice #0 > > Just give a name to .stream_name, not to fix any issue but just decorate the > output. > After applying this patch, the output becomes: > root@xilinx-zynqmp:~# aplay -l > List of PLAYBACK Hardware Devices > card 0: monitor [DisplayPort monitor], device 0: xilinx-dp0 > xilinx-dp-snd-codec-dai-0 [xilinx-dp0 xilinx-dp-snd-codec-dai-0] > Subdevices: 1/1 > Subdevice #0: subdevice #0 > card 0: monitor [DisplayPort monitor], device 1: xilinx-dp1 > xilinx-dp-snd-codec-dai-1 [xilinx-dp1 xilinx-dp-snd-codec-dai-1] > Subdevices: 1/1 > Subdevice #0: subdevice #0 > > Would you please help review and merge these patches to linux-yocto > v5.2/standard/xlnx-soc branch? > I see the review is in, so this is now merged to the soc branch Bruce > Quanyang Wang (1): > sound: soc: xilinx: give a name to stream_name in xilinx_dp_dai_links > > sound/soc/xilinx/xilinx-dp-card.c | 2 ++ > 1 file changed, 2 insertions(+) > > -- > 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
Re: [linux-yocto] [linux-yocto-dev]: [kernel standard/bcm-2xxx-rpi]: bcm-2xxx-rpi: Revert "cgroup: Disable cgroup "memory" by default"
On Tue, Nov 19, 2019 at 11:43 PM wrote: > > From: Limeng > > Hi Bruce, > > After kts test, we found out cgroup case failed. > The reason is that raspberrypi SDK kernel disable cgroup "memory" feature. > > It is not reasonable to disable a common cgroup feature. > Because there is enough memory on latest raspberrypi 4 platform. > reverted. Bruce > Could you please help to merge this patch into branch standard/bcm-2xxx-rpi, > linux-ycoto-dev kernel. > > diffstat info ad below: > > cgroup.c | 30 -- > 1 file changed, 30 deletions(-) > > > thanks, > Limeng -- - 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] [mariadb] I'm getting an error when I include mariadb in sdk build
I'm building thud for raspberrypi3 with boot2qt. I've got mariadb included in my rpi image and it is working fine, I've got a problem with Qt's latest release that when I include mariadb in the sdk build I get the following error: ERROR: meta-toolchain-b2qt-embedded-qt5-sdk-1.0-r0 do_populate_sdk: Unable to install packages. Command '/home/gwilson/Qt/Qt-5.13.2/Yocto-build-RPi3/build-raspberrypi3/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/meta-toolchain-b2qt-embedded-qt5-sdk/1.0-r0/recipe-sysroot-native/usr/bin/opkg --volatile-cache -f /home/gwilson/Qt/Qt-5.13.2/Yocto-build-RPi3/build-raspberrypi3/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/meta-toolchain-b2qt-embedded-qt5-sdk/1.0-r0/opkg.conf -t /home/gwilson/Qt/Qt-5.13.2/Yocto-build-RPi3/build-raspberrypi3/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/meta-toolchain-b2qt-embedded-qt5-sdk/1.0-r0/temp/ipktemp/ -o /home/gwilson/Qt/Qt-5.13.2/Yocto-build-RPi3/build-raspberrypi3/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/meta-toolchain-b2qt-embedded-qt5-sdk/1.0-r0/sdk/image/opt/b2qt/2.6.2/sysroots/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi --force_postinstall --prefer-arch-to-version install packagegroup-b2qt-embedded-qt5-toolchain-target packagegroup-core-standalone-sdk-target target-sdk-provides-dummy' returned 1: Collected errors: * Solver encountered 1 problem(s): * Problem 1/1: * - package libdbi-perl-1.641-r0.cortexa7t2hf-neon-vfpv4 requires perl-module-dynaloader, but none of the providers can be installed * * Solution 1: * - do not ask to install a package providing target-sdk-provides-dummy * Solution 2: * - do not ask to install a package providing packagegroup-b2qt-embedded-qt5-toolchain-target ERROR: meta-toolchain-b2qt-embedded-qt5-sdk-1.0-r0 do_populate_sdk: Function failed: do_populate_sdk ERROR: Logfile of failure stored in: /home/gwilson/Qt/Qt-5.13.2/Yocto-build-RPi3/build-raspberrypi3/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/meta-toolchain-b2qt-embedded-qt5-sdk/1.0-r0/temp/log.do_populate_sdk.29846 ERROR: Task (/home/gwilson/Qt/Qt-5.13.2/Yocto-build-RPi3/sources/meta-boot2qt/meta-boot2qt-distro/recipes-qt/meta/meta-toolchain-b2qt-embedded-qt5-sdk.bb:do_populate_sdk) failed with exit code '1' I've searched for answers and haven't been able to find any. If anyone has any insight I would appreciate the help. Regards, Greg Wilson-Lindberg -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Doubt regarding python-elementtree rpm
On 11/20/19 9:05 AM, Varun A wrote: Hi Had a doubt. While building python3 rpms using python 3.4.3 bit bake file, I am noticing that python-elementtree rpm is missing. It used to be available in package feeds in python 2.7 case. Has it been merged with another RPM? If so which one. Regards Varun It was merged into python-xml: python: merge python-elementtree into python-xml https://git.openembedded.org/openembedded-core/commit/?id=5f7206eba3953b7f29148ecfb791995773ee5fc7 -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Review request 0/13: Contribute meta-tensorflow to Yocto
On 11/20/19 11:56 AM, Mauro Ziliani wrote: Is it possible to compile tensorflow against python2.7? I doubt that it's easy/supported but Hongxu, who lives in China, will reply later today to explain. Btw, Krogoth has python3, why not use it? ../Randy Il 20/11/19 16:40, Mauro Ziliani ha scritto: I forked the repository and I'm tryng to port the layer for Krogoth M Il 20/11/19 15:37, Mauro Ziliani ha scritto: Hi all. There a port for meta-tensorflow for Krogoth or Sumo? Mayabe I need to use it on this distribution Thaks M Il 21/02/19 12:37, Hongxu Jia ha scritto: Hi RP and Yocto folks, Currently AI on IoT edge becomes more and more popular, but there is no machine learning framework in Yocto/OE. With the support of Eric , Robert and Randy, after two months effort, I've integrated TensorFlow to Yocto. Now, I contribute the patches to Yocto for review, and apply for creating a layer named `meta-tensorflow' on Yocto. For test convenient, there is a fork on github: https://github.com/hongxu-jia/meta-tensorflow BTW, I have contributed other 11 fundamental recipes to meta-openembedded and all of them have been merged to master branch. Please no hesitate to share your suggestion. //Hongxu Testing Commands: - See README Testing, Expected Results: -- See README -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-gplv2][PATCH] diffutils: fix the build with musl
This patch fixes the build with musl using the included regex library.
It follows a similar patch applied to grep (uclibc-fix.patch)
Signed-off-by: Nicola Lunghi
---
.../0002-uclibc-use-mempcpy-instead-of.patch | 53 +++
recipes-extended/diffutils/diffutils.inc | 8 ---
recipes-extended/diffutils/diffutils_2.8.1.bb | 4 ++
3 files changed, 57 insertions(+), 8 deletions(-)
create mode 100644
recipes-extended/diffutils/diffutils-2.8.1/0002-uclibc-use-mempcpy-instead-of.patch
diff --git
a/recipes-extended/diffutils/diffutils-2.8.1/0002-uclibc-use-mempcpy-instead-of.patch
b/recipes-extended/diffutils/diffutils-2.8.1/0002-uclibc-use-mempcpy-instead-of.patch
new file mode 100644
index 000..a07fec7
--- /dev/null
+++
b/recipes-extended/diffutils/diffutils-2.8.1/0002-uclibc-use-mempcpy-instead-of.patch
@@ -0,0 +1,53 @@
+From 61db4da387676690c0f731ef2eccc014d85c23a6 Mon Sep 17 00:00:00 2001
+From: Nicola Lunghi
+Date: Wed, 20 Nov 2019 18:30:10 +
+Subject: [PATCH] uclibc: use mempcpy instead of __mempcpy
+
+Fix to use mempcpy instead of __mempcpy. This is needed for uclibc which
+doesn't define __mempcpy, only mempcpy. Since both uclibc and glibc have
+mempcpy, we'll just use that instead.
+Patch source: OpenEmbedded (grep)
+Upstream-Status: Inappropriate [licensing]
+---
+ lib/getopt.c | 4 ++--
+ lib/regex.c | 2 +-
+ 2 files changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/lib/getopt.c b/lib/getopt.c
+index ed32692..6626f5e 100644
+--- a/lib/getopt.c
b/lib/getopt.c
+@@ -334,7 +334,7 @@ exchange (argv)
+ nonoption_flags_len = nonoption_flags_max_len = 0;
+ else
+ {
+-memset (__mempcpy (new_str, __getopt_nonoption_flags,
++memset (mempcpy (new_str, __getopt_nonoption_flags,
+nonoption_flags_max_len),
+ '\0', top + 1 - nonoption_flags_max_len);
+ nonoption_flags_max_len = top + 1;
+@@ -445,7 +445,7 @@ _getopt_initialize (argc, argv, optstring)
+ if (__getopt_nonoption_flags == NULL)
+ nonoption_flags_max_len = -1;
+ else
+- memset (__mempcpy (__getopt_nonoption_flags, orig_str, len),
++ memset (mempcpy (__getopt_nonoption_flags, orig_str, len),
+ '\0', nonoption_flags_max_len - len);
+ }
+ }
+diff --git a/lib/regex.c b/lib/regex.c
+index 6daec76..797b20a 100644
+--- a/lib/regex.c
b/lib/regex.c
+@@ -8314,7 +8314,7 @@ regerror (errcode, preg, errbuf, errbuf_size)
+ if (msg_size > errbuf_size)
+ {
+ #if defined HAVE_MEMPCPY || defined _LIBC
+-*((char *) __mempcpy (errbuf, msg, errbuf_size - 1)) = '\0';
++*((char *) mempcpy (errbuf, msg, errbuf_size - 1)) = '\0';
+ #else
+ memcpy (errbuf, msg, errbuf_size - 1);
+ errbuf[errbuf_size - 1] = 0;
+--
+2.20.1
+
diff --git a/recipes-extended/diffutils/diffutils.inc
b/recipes-extended/diffutils/diffutils.inc
index 243341a..5e82b81 100644
--- a/recipes-extended/diffutils/diffutils.inc
+++ b/recipes-extended/diffutils/diffutils.inc
@@ -6,13 +6,5 @@ SECTION = "base"
inherit autotools texinfo update-alternatives gettext
-# diffutils assumes non-glibc compilation with uclibc and
-# this causes it to generate its own implementations of
-# standard functionality. regex.c actually breaks compilation
-# because it uses __mempcpy, there are other things (TBD:
-# see diffutils.mk in buildroot)
-EXTRA_OECONF_libc-uclibc = "--without-included-regex"
-
ALTERNATIVE_${PN} = "diff cmp"
ALTERNATIVE_PRIORITY = "100"
-
diff --git a/recipes-extended/diffutils/diffutils_2.8.1.bb
b/recipes-extended/diffutils/diffutils_2.8.1.bb
index 466bf28..931c973 100644
--- a/recipes-extended/diffutils/diffutils_2.8.1.bb
+++ b/recipes-extended/diffutils/diffutils_2.8.1.bb
@@ -9,11 +9,15 @@ SRC_URI = "${GNU_MIRROR}/diffutils/diffutils-${PV}.tar.gz \
file://diffutils_fix_for_automake-1.12.patch \
file://fix_gcc6.patch \
file://0001-Make-it-build-with-compile-time-hardening-enabled.patch
\
+ file://0002-uclibc-use-mempcpy-instead-of.patch \
"
SRC_URI[md5sum] = "71f9c5ae19b60608f6c7f162da86a428"
SRC_URI[sha256sum] =
"c5001748b069224dd98bf1bb9ee877321c7de8b332c8aad5af3e2a7372d23f5a"
+EXTRA_OECONF = "--without-included-regex"
+EXTRA_OECONF_libc-musl = "--with-included-regex"
+
do_configure_prepend () {
chmod u+w ${S}/po/Makefile.in.in
}
--
2.20.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Review request 0/13: Contribute meta-tensorflow to Yocto
Is it possible to compile tensorflow against python2.7? Il 20/11/19 16:40, Mauro Ziliani ha scritto: I forked the repository and I'm tryng to port the layer for Krogoth M Il 20/11/19 15:37, Mauro Ziliani ha scritto: Hi all. There a port for meta-tensorflow for Krogoth or Sumo? Mayabe I need to use it on this distribution Thaks M Il 21/02/19 12:37, Hongxu Jia ha scritto: Hi RP and Yocto folks, Currently AI on IoT edge becomes more and more popular, but there is no machine learning framework in Yocto/OE. With the support of Eric , Robert and Randy, after two months effort, I've integrated TensorFlow to Yocto. Now, I contribute the patches to Yocto for review, and apply for creating a layer named `meta-tensorflow' on Yocto. For test convenient, there is a fork on github: https://github.com/hongxu-jia/meta-tensorflow BTW, I have contributed other 11 fundamental recipes to meta-openembedded and all of them have been merged to master branch. Please no hesitate to share your suggestion. //Hongxu Testing Commands: - See README Testing, Expected Results: -- See README -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Review request 0/13: Contribute meta-tensorflow to Yocto
I forked the repository and I'm tryng to port the layer for Krogoth M Il 20/11/19 15:37, Mauro Ziliani ha scritto: Hi all. There a port for meta-tensorflow for Krogoth or Sumo? Mayabe I need to use it on this distribution Thaks M Il 21/02/19 12:37, Hongxu Jia ha scritto: Hi RP and Yocto folks, Currently AI on IoT edge becomes more and more popular, but there is no machine learning framework in Yocto/OE. With the support of Eric , Robert and Randy, after two months effort, I've integrated TensorFlow to Yocto. Now, I contribute the patches to Yocto for review, and apply for creating a layer named `meta-tensorflow' on Yocto. For test convenient, there is a fork on github: https://github.com/hongxu-jia/meta-tensorflow BTW, I have contributed other 11 fundamental recipes to meta-openembedded and all of them have been merged to master branch. Please no hesitate to share your suggestion. //Hongxu Testing Commands: - See README Testing, Expected Results: -- See README -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Doubt regarding python-elementtree rpm
Hi Had a doubt. While building python3 rpms using python 3.4.3 bit bake file, I am noticing that python-elementtree rpm is missing. It used to be available in package feeds in python 2.7 case. Has it been merged with another RPM? If so which one. Regards Varun -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [layerindex-web][PATCH 0/6] Recipe search improvements, misc fixes [cover letter only]
Some minor improvements to recipe searching, plus fixes for a couple of issues I noticed while doing the RRS rework. Note: this patchset is on top of paule/recipesymbol. The following changes since commit 6f85a1b4589df08e849a106338fe03d72e2394c2: TODO: add some more tasks (2019-11-21 02:51:30 +1300) are available in the Git repository at: git://git.yoctoproject.org/layerindex-web paule/fixes14 http://git.yoctoproject.org/cgit.cgi/layerindex-web/log/?h=paule/fixes14 Paul Eggleton (6): Drop LICENSE.diff2html update: fix exception with -x/--nofetch option recipes: improved support for queries containing quotes recipes: support pn: query prefix recipes: allow searching for layer:oe-core recipes: add help button to explain search terms layerindex/static/LICENSE.diff2html | 20 layerindex/update.py| 50 ++--- layerindex/views.py | 23 +++-- templates/layerindex/recipes.html | 22 + 4 files changed, 68 insertions(+), 47 deletions(-) delete mode 100644 layerindex/static/LICENSE.diff2html -- 2.20.1 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [layerindex-web][PATCH 00/29] RRS: rework upgrade history collection [cover letter only]
Taking a hard look at the recipe upgrade functionality, there were a number of shortcomings in how the data was collected which led to upgrades being missed, history disappearing when recipes were removed or renamed and scenarios such as multiple recipes with the same name not being handled correctly. This patchset introduces the concept of a RecipeSymbol (acting as an umbrella for RRS records for the same named recipe but independent of actual Recipe records which may be transient) and also fixes a number of issues in the upgrade data collection for much greater accuracy. The following changes since commit 50fc6780e022a95b452fdb6f57b4e1c6b37084f2: requirements.txt: bump a couple more versions (2019-10-29 10:22:59 +1300) are available in the Git repository at: git://git.yoctoproject.org/layerindex-web paule/recipesymbol http://git.yoctoproject.org/cgit.cgi/layerindex-web/log/?h=paule/recipesymbol Paul Eggleton (29): RRS: collect history independent of current recipes RRS: Add deleted recipe handling RRS: use more robust RFC2822 date conversion RRS: skip problematic OE-Core commits (when a dependency) RRS: handle downgrades RRS: use more robust method of getting last upgrade record rrs_upgrade_history: record start marker in log file RRS: handle recipe moves without overwriting data RRS: support grouping upgrades by version for multi-version recipes RRS: use RecipeUpgradeGroup to determine downgrades RRS: detect PN changing without move rrs_upgrade_history: implement file path filtering RRS: record previous version rrs_upgrade_history: add stop commit option RRS: fixup handling of upgrades where recipe moved to inc RRS: fix some more bad OE-Core commits RRS: ensure upgrades recorded at exact same time are correctly ordered RRS: avoid historical parsing bug in bitbake recipeparse: handle recipes at root of repository RRS: handle when recipes get deleted and later re-added RRS: exclude lib/ subdirectory of layers to avoid picking up templates RRS: ensure default URLs for release/milestone are the latest RRS: detect changes in SRCREV as upgrades RRS: Add tool to dump upgrades RRS: enable grouping recipe upgrades by license RRS: Handle two versions added on same day then later one deleted Add recipe dependencies tool RRS: do not ignore non-numeric characters in versions TODO: add some more tasks TODO | 16 + layerindex/admin.py | 1 + layerindex/forms.py | 13 + .../migrations/0044_extendedprovides.py | 46 ++ layerindex/models.py | 8 + layerindex/recipeparse.py | 19 +- layerindex/update_layer.py| 2 + layerindex/urls.py| 6 +- layerindex/views.py | 116 - rrs/admin.py | 26 +- rrs/migrations/0020_recipesymbol_initial.py | 63 +++ rrs/migrations/0021_recipesymbol_nonnull.py | 31 ++ rrs/migrations/0022_recipesymbol_finish.py| 27 ++ rrs/migrations/0023_recipeupgrade_deleted.py | 25 + .../0024_recipeupgrade_downgrade.py | 20 + rrs/migrations/0025_recipeupgrade_move.py | 25 + rrs/migrations/0026_recipeupgrade_grouping.py | 39 ++ .../0027_recipeupgrade_prev_version.py| 20 + rrs/migrations/0028_recipeupgrade_srcrev.py | 20 + rrs/migrations/0029_rrs_license_group.py | 44 ++ rrs/models.py | 145 +- rrs/tools/common.py | 12 +- rrs/tools/dump_upgrades.py| 89 rrs/tools/rrs_maintainer_history.py | 32 +- rrs/tools/rrs_upgrade_history.py | 68 ++- rrs/tools/rrs_upstream_history.py | 36 +- rrs/tools/upgrade_history_internal.py | 431 +++--- rrs/views.py | 177 --- templates/base.html | 1 + templates/layerindex/recipedeps.html | 209 + templates/rrs/recipedetail.html | 27 +- 31 files changed, 1598 insertions(+), 196 deletions(-) create mode 100644 layerindex/migrations/0044_extendedprovides.py create mode 100644 rrs/migrations/0020_recipesymbol_initial.py create mode 100644 rrs/migrations/0021_recipesymbol_nonnull.py create mode 100644 rrs/migrations/0022_recipesymbol_finish.py create mode 100644 rrs/migrations/0023_recipeupgrade_deleted.py create mode 100644 rrs/migrations/0024_recipeupgrade_downgrade.py create mode 100644 rrs/migrations/0025_recipeupgrade_move.py create mode 100644 rrs/migrations/0026_recipeupgrade_grouping.py create mode 100644 rrs/migrations/0027_recipeupgrade_prev_version.py create mode 100644 rrs/migrations/0028_recipeupgrade_srcrev.py create mode 100644 rrs/migrations/0029_rrs_license_group.py create mode 100755 rrs/tools/dump_upgrades.py create mode
Re: [yocto] Install native recipe into filesystem
On 19/11/2019 21:15, Jeff Kaisner wrote: We have several executables that can run on the target (ARM64) but also on the host system (x86). I added the BBCLASSEXTEND = "native" and can build all the recipes in native mode. Once done, I would like to be able to install them on the host system, but don’t see a package for them (or understand that part of the process). I'm guessing you have a recipe called something like foo.bb. You've added BBCLASSEXTEND=native to this, and can bitbake foo-native. If you want to also build this for the target, simply add foo to the IMAGE_DEPENDS or directly bitbake foo. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [musl] CC option -mmusl in SDK env script but not in default do_compile task
Hi all, I've recently noticed a mismatch between CC options - set by the SDK environment script - set by the do_compile task for any 'target' class recipes when the DISTRO is configured with TCLIBC = "musl" The SDK env script adds "-mmusl" when exporting CC while do_compile doesn't. We can see TARGET_CC_ARCH_append_libc-musl = " -mmusl" in file meta/classes/toolchain-scripts.bbclass, this class is inherited when building the meta-environment- recipe (dependancy of the populate_sdk task of core images). Can anyone explain what is the aim of this -mmusl option and if required why this option is not set on both sides ? I fear this could lead to some situations where applications built from the SDK and then built with the full Yocto stack don't behave exactly the same. Thanks Antoine -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [warrior] [meta-qt4] 3rdparty: javascriptcore: JITStubs.cpp: allow builds of JavaScriptCore with gcc v8
Hi Mike, On Wed, Nov 20, 2019 at 09:06:08PM +1300, Paul Eggleton wrote: > Hi Mike > > On Wednesday, 20 November 2019 9:00:10 PM NZDT Mike Looijmans wrote: > > I ran into this issue yesterday, and this patch solves the compilation on > > warrior. However, it's a patch for Qt itself, and not for OE. > > > > Is there already a warrior patch in the making, or should I submit one? > > Quentin sent one yesterday (with the same subject). If you could give it a > try > and confirm it fixes the failure that would be great. > Yes, I was too excited to send the patch and forgot I needed to send a patch for meta-qt4 containing the patch for the qt4 sources. *facepalm* You should be able to get the patch for meta-qt4 from: https://lists.yoctoproject.org/pipermail/yocto/2019-November/047405.html Let us know if the patch applies nicely and fixes your issue (it should), Thanks, Quentin -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] bitbake SRC_URI fetch Azure DevOps repository Azure DevOps Services Basic
Hi Richard, Thanks for your patch which could work for us. I study git-clone document and found the git urls support alternative scp-like syntax like below: [user@]host.xz:path/to/repo.git/ It seems like Azure DevOps provides SSH url. Will yocto support this alternative url? Thanks, Samuel Jiang -Original Message- From: Richard Purdie Sent: Thursday, November 14, 2019 2:52 AM To: Samuel Jiang (江騏先) ; yocto@yoctoproject.org Cc: Alex Chong Subject: Re: [yocto] bitbake SRC_URI fetch Azure DevOps repository Azure DevOps Services Basic On Wed, 2019-11-13 at 09:02 +, Samuel Jiang (江騏先) wrote: > I got below error message: > crashdump-git-r0 do_fetch: Fetcher failure: Fetch command export > PSEUDO_DISABLED=1; unset _PYTHON_SYSCONFIGDATA_NAME; export > DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus"; export > SSH_AGENT_PID="2255"; export SSH_AUTH_SOCK="/run/user/1000/keyring/ssh"; > export PATH="[private_data]"; export HOME="/home/samueljiang"; git -c > core.fsyncobjectfiles=0 ls-remote > git://quanta01.visualstudio.com/OpenBMC/_git/crashdump failed with exit code > 128, output: > fatal: unable to connect to quanta01.visualstudio.com: > quanta01.visualstudio.com[0: 2620:1ec:21::18]: errno=Network is > unreachable > quanta01.visualstudio.com[1: 13.107.42.18]: errno=Connection timed out > > Seems this url with git:// prefix could not connect in Azure DevOps > > Document[https://docs.microsoft.com/en-us/azure/devops/repos/git/use-ssh-keys-to-authenticate?view=azure-devops]. I now realise what the problem is. Whatever this git server you're talking to is, it does not work the same as is documented for the "git clone" manpage. There is no option to force bitbake to use the syntax you're asking for since the manpage says the synax its using is valid. You could patch bitbake to force it to use that syntax with a patch like: diff --git a/bitbake/lib/bb/fetch2/git.py b/bitbake/lib/bb/fetch2/git.py index fa41b078f12..f20c1f36b82 100644 --- a/bitbake/lib/bb/fetch2/git.py +++ b/bitbake/lib/bb/fetch2/git.py @@ -588,6 +588,8 @@ class Git(FetchMethod): username = ud.user + '@' else: username = "" +if ud.proto == "ssh": +return "%s%s:%s" % (username, ud.host, ud.path[1:]) return "%s://%s%s%s" % (ud.proto, username, ud.host, ud.path) def _revision_key(self, ud, d, name): which in my local tests appeared to give the result you're asking for but that shouldn't be required with a server that adheres to what the git manual says is supported. Cheers, Richard -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [warrior] [meta-qt4] 3rdparty: javascriptcore: JITStubs.cpp: allow builds of JavaScriptCore with gcc v8
Hi Mike On Wednesday, 20 November 2019 9:00:10 PM NZDT Mike Looijmans wrote: > I ran into this issue yesterday, and this patch solves the compilation on > warrior. However, it's a patch for Qt itself, and not for OE. > > Is there already a warrior patch in the making, or should I submit one? Quentin sent one yesterday (with the same subject). If you could give it a try and confirm it fixes the failure that would be great. Thanks Paul -- Paul Eggleton Intel System Software Products -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [warrior] [meta-qt4] 3rdparty: javascriptcore: JITStubs.cpp: allow builds of JavaScriptCore with gcc v8
I ran into this issue yesterday, and this patch solves the compilation on
warrior. However, it's a patch for Qt itself, and not for OE.
Is there already a warrior patch in the making, or should I submit one?
On 19-11-19 13:37, Quentin Schulz wrote:
> At least since gcc v8, source code with asm volatile won't compile
> anymore.
>
> The volatile qualifier anyway is a no-op since asm blocks are implicitly
> volatile as written in the documentation[1].
>
> Let's get rid of this redundant qualifier so we can build with newer
> GCCs.
>
> The resulting error message is the following (note that there is a
> bunch of them):
> ../3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp:617:5: error:
> expected '(' before 'volatile'
> asm volatile (
> ^~~~
> (
> ../3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp:618:1: error:
> expected unqualified-id before string constant
> ".text\n"
> ^
> ../3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp:617:15: error:
> expected ')' before string constant
> asm volatile (
> ~^
> )
> ".text\n"
> ~
>
> [1] https://gcc.gnu.org/onlinedocs/gcc/Basic-Asm.html#Basic-Asm
>
> Upstream-Status: Inappropriate
> Signed-off-by: Quentin Schulz
> ---
> .../JavaScriptCore/jit/JITStubs.cpp | 48 +--
> 1 file changed, 24 insertions(+), 24 deletions(-)
>
> diff --git a/src/3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp
> b/src/3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp
> index d8027ff2..dcead6d0 100644
> --- a/src/3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp
> +++ b/src/3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp
> @@ -116,7 +116,7 @@ COMPILE_ASSERT(offsetof(struct JITStackFrame, savedEBX)
> == 0x3c, JITStackFrame_s
> COMPILE_ASSERT(offsetof(struct JITStackFrame, callFrame) == 0x58,
> JITStackFrame_callFrame_offset_matches_ctiTrampoline);
> COMPILE_ASSERT(offsetof(struct JITStackFrame, code) == 0x50,
> JITStackFrame_code_offset_matches_ctiTrampoline);
>
> -asm volatile (
> +asm (
> ".text\n"
> ".globl " SYMBOL_STRING(ctiTrampoline) "\n"
> HIDE_SYMBOL(ctiTrampoline) "\n"
> @@ -138,7 +138,7 @@ SYMBOL_STRING(ctiTrampoline) ":" "\n"
> "ret" "\n"
> );
>
> -asm volatile (
> +asm (
> ".globl " SYMBOL_STRING(ctiVMThrowTrampoline) "\n"
> HIDE_SYMBOL(ctiVMThrowTrampoline) "\n"
> SYMBOL_STRING(ctiVMThrowTrampoline) ":" "\n"
> @@ -154,7 +154,7 @@ SYMBOL_STRING(ctiVMThrowTrampoline) ":" "\n"
> "ret" "\n"
> );
>
> -asm volatile (
> +asm (
> ".globl " SYMBOL_STRING(ctiOpThrowNotCaught) "\n"
> HIDE_SYMBOL(ctiOpThrowNotCaught) "\n"
> SYMBOL_STRING(ctiOpThrowNotCaught) ":" "\n"
> @@ -179,7 +179,7 @@ COMPILE_ASSERT(offsetof(struct JITStackFrame, savedRBX)
> == 0x48, JITStackFrame_s
> COMPILE_ASSERT(offsetof(struct JITStackFrame, callFrame) == 0x90,
> JITStackFrame_callFrame_offset_matches_ctiTrampoline);
> COMPILE_ASSERT(offsetof(struct JITStackFrame, code) == 0x80,
> JITStackFrame_code_offset_matches_ctiTrampoline);
>
> -asm volatile (
> +asm (
> ".globl " SYMBOL_STRING(ctiTrampoline) "\n"
> HIDE_SYMBOL(ctiTrampoline) "\n"
> SYMBOL_STRING(ctiTrampoline) ":" "\n"
> @@ -206,7 +206,7 @@ SYMBOL_STRING(ctiTrampoline) ":" "\n"
> "ret" "\n"
> );
>
> -asm volatile (
> +asm (
> ".globl " SYMBOL_STRING(ctiVMThrowTrampoline) "\n"
> HIDE_SYMBOL(ctiVMThrowTrampoline) "\n"
> SYMBOL_STRING(ctiVMThrowTrampoline) ":" "\n"
> @@ -222,7 +222,7 @@ SYMBOL_STRING(ctiVMThrowTrampoline) ":" "\n"
> "ret" "\n"
> );
>
> -asm volatile (
> +asm (
> ".globl " SYMBOL_STRING(ctiOpThrowNotCaught) "\n"
> HIDE_SYMBOL(ctiOpThrowNotCaught) "\n"
> SYMBOL_STRING(ctiOpThrowNotCaught) ":" "\n"
> @@ -242,7 +242,7 @@ SYMBOL_STRING(ctiOpThrowNotCaught) ":" "\n"
> #error "JIT_STUB_ARGUMENT_VA_LIST not supported on ARMv7."
> #endif
>
> -asm volatile (
> +asm (
> ".text" "\n"
> ".align 2" "\n"
> ".globl " SYMBOL_STRING(ctiTrampoline) "\n"
> @@ -269,7 +269,7 @@ SYMBOL_STRING(ctiTrampoline) ":" "\n"
> "bx lr" "\n"
> );
>
> -asm volatile (
> +asm (
> ".text" "\n"
> ".align 2" "\n"
> ".globl " SYMBOL_STRING(ctiVMThrowTrampoline) "\n"
> @@ -287,7 +287,7 @@ SYMBOL_STRING(ctiVMThrowTrampoline) ":" "\n"
> "bx lr" "\n"
> );
>
> -asm volatile (
> +asm (
> ".text" "\n"
> ".align 2" "\n"
> ".globl " SYMBOL_STRING(ctiOpThrowNotCaught) "\n"
> @@ -305,7 +305,7 @@ SYMBOL_STRING(ctiOpThrowNotCaught) ":" "\n"
>
> #elif COMPILER(GCC) && CPU(ARM_TRADITIONAL)
>
> -asm volatile (
> +asm (
> ".globl " SYMBOL_STRING(ctiTrampoline) "\n"
> HIDE_SYMBOL(ctiTrampoline) "\n"
> SYMBOL_STRING(ctiTrampoline) ":" "\n"
> @@ -323,7 +323,7 @@ SYMBOL_STRING(ctiTrampoline) ":" "\n"
> "mov pc, lr" "\n"
> );
>
> -asm volatile (
> +asm (
> ".globl " SYMBOL_STRING(ctiVMThrowTrampoline) "\n"
> HIDE_SYMBOL(ctiVMThrowTrampoline) "\n"
> SYMBOL_STRING(ctiVMThrowTrampoline) ":" "\n"
> @@
