Date   

Re: oeqa: test cases at the end of the test suite

Alexander Kanavin
 

I'd say improving the actual test ordering function is the way to go, yes. Not sure how the ordering 'hint' should be like, but maybe setting an integer priority via a decorator would work:
@OETestPriority(1) ---> runs first, no guarantees about relative order of other tests with priority 1.
@OETestPriority(99) ---> runs last, ditto.
Default priority: 50 or similar.

Alex


On Mon, 4 Jan 2021 at 11:51, Konrad Weihmann <kweihmann@...> wrote:
Hi all,

I have a few oeqa test cases, which always should run last in a test
suite (log and file collectors for instance).
Due to the ordering of the test case discovery I had to name all those
tests like "zzz_<name>" to move them to the end of the computed list.

Unfortunately this is very error prone, as the OETestDepends tag does
have major influence on the ordering (just a single misplaced tag in any
test case can make it past those "zzz" cases).
Also it makes things hard to read IMO.

That brings me to my question, is there any way to ensure that test
cases are run at the end of the complete list of test suites?

If not does anyone have an idea how to create such a feature (maybe a
new decorator or something like that)?

Regards
Konrad




Re: How do I build an x32 Intel system?

morgan.hill@...
 

Other than the first one, I don't know whether these are correct, or
where I
originally got them, or if there's a stock .cfg file that does all
this.
I'm not familiar with x32 myself but Debian has an x32port which should
give you a working kernel config to start from.
https://wiki.debian.org/X32Port


--

<http://holoplot.com/?utm_source=email&utm_medium=sg&utm_campaign=Holoplot_Signature+>

<https://holoplot.com/>*HOLOPLOT GmbH - Headquarters*


Ringbahnstr. 12
(10-14) / A2

12099 Berlin, Germany

+49 (0) 30 40745812




*HOLOPLOT GmbH
- Manufacturing*


Alboinstr. 17-23 / Hall 12

12103 Berlin, Germany

+49
(0) 30 959988740


www.holoplot.com <https://holoplot.com/>



Follow us on
<https://www.facebook.com/OriginalHOLOPLOT/?utm_source=email&utm_medium=sg&utm_campaign=Holoplot_Signature+>
LinkedIn
<https://www.linkedin.com/company/holoplot-gmbh?utm_source=email&utm_medium=sg&utm_campaign=Holoplot_Signature+>.




Roman Sick – CEO | HRB183974B, Register Court Charlottenburg, Germany |
EU Tax-Registration No. DE277000701 This e-mail contains confidential
and/or privileged information. If you are not the intended recipient (or
have received this e-mail in error) please notify the sender immediately
and destroy this e-mail. Any unauthorized copying, disclosure or
distribution of the information in this e-mail is strictly forbidden.


oeqa: test cases at the end of the test suite

Konrad Weihmann
 

Hi all,

I have a few oeqa test cases, which always should run last in a test suite (log and file collectors for instance).
Due to the ordering of the test case discovery I had to name all those tests like "zzz_<name>" to move them to the end of the computed list.

Unfortunately this is very error prone, as the OETestDepends tag does have major influence on the ordering (just a single misplaced tag in any test case can make it past those "zzz" cases).
Also it makes things hard to read IMO.

That brings me to my question, is there any way to ensure that test cases are run at the end of the complete list of test suites?

If not does anyone have an idea how to create such a feature (maybe a new decorator or something like that)?

Regards
Konrad


oeqa: testcase caching

Konrad Weihmann
 

Hi all,

I have a bunch of custom testcases (oeqa/runtime/cases) which are interacting with "d" from the build host - basically fetching some info while executing the test, e.g.

foo = self.tc.td['MY_CUSTOM_VAR']

What I've seen is that these files create python __pycache__ files during parsing of the testimage run.

On the initial run everything is working like expected, but if I now change the variable "MY_CUSTOM_VAR", without modifying the target-filesystem the value inside the test case doesn't get updated.

Did anyone else encountered this?

To me it seems like the value of the var does make it into the pycache files, ignoring the updated value on a second run.

On that note: wouldn't it make sense to disable the cache creation for oeqa test cases? just to mitigate chances of such scenarios?

Or maybe I'm doing something wrong here, so any pointers are highly appreciated.

Regards
Konrad


Re: [meta-tensorflow][PATCH 8/25] tensorflow-estimator: 1.13 -> 2.4

Marek Belisko
 

Hi Hongxu,

On Wed, Dec 16, 2020 at 2:09 PM Hongxu Jia <hongxu.jia@windriver.com> wrote:

Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
---
.../0001-customize-for-yocto.patch | 28 +++++++++++++++++++
.../tensorflow/tensorflow-estimator_1.13.bb | 12 ++++++--
2 files changed, 37 insertions(+), 3 deletions(-)
create mode 100644 recipes-framework/tensorflow/tensorflow-estimator/0001-customize-for-yocto.patch

diff --git a/recipes-framework/tensorflow/tensorflow-estimator/0001-customize-for-yocto.patch b/recipes-framework/tensorflow/tensorflow-estimator/0001-customize-for-yocto.patch
new file mode 100644
index 0000000..e9b66d5
--- /dev/null
+++ b/recipes-framework/tensorflow/tensorflow-estimator/0001-customize-for-yocto.patch
@@ -0,0 +1,28 @@
+From a1bcf09a43fc44ad5e04c441ee45cc23d16cf7d2 Mon Sep 17 00:00:00 2001
+From: Hongxu Jia <hongxu.jia@windriver.com>
+Date: Wed, 9 Dec 2020 17:59:01 +0800
+Subject: [PATCH] customize for yocto
+
+Upstream-Status: Inappropriate [oe specific]
+
+Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
+---
+ tensorflow_estimator/tools/pip_package/build_pip_package.sh | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/tensorflow_estimator/tools/pip_package/build_pip_package.sh b/tensorflow_estimator/tools/pip_package/build_pip_package.sh
+index d4953a6..e08cd8a 100755
+--- a/tensorflow_estimator/tools/pip_package/build_pip_package.sh
++++ b/tensorflow_estimator/tools/pip_package/build_pip_package.sh
+@@ -38,7 +38,7 @@ function prepare_src() {
+
+ # Verifies all expected files are in pip.
+ # Creates init files in all directory in pip.
+- python tensorflow_estimator/tools/pip_package/create_pip_helper.py --pip-root "${TMPDIR}/tensorflow_estimator/" --bazel-root "./tensorflow_estimator"
++ nativepython3 tensorflow_estimator/tools/pip_package/create_pip_helper.py --pip-root "${TMPDIR}/tensorflow_estimator/" --bazel-root "./tensorflow_estimator"
+ }
+
+ function build_wheel() {
+--
+2.18.2
+
diff --git a/recipes-framework/tensorflow/tensorflow-estimator_1.13.bb b/recipes-framework/tensorflow/tensorflow-estimator_1.13.bb
index f3a5098..5b2fe5d 100644
--- a/recipes-framework/tensorflow/tensorflow-estimator_1.13.bb
+++ b/recipes-framework/tensorflow/tensorflow-estimator_1.13.bb
@@ -3,9 +3,10 @@ learning programming."
LICENSE = "Apache-2.0"
LIC_FILES_CHKSUM = "file://LICENSE;md5=01e86893010a1b87e69a213faa753ebd"

-SRC_URI = "git://github.com/tensorflow/estimator.git;branch=r1.13 \
+SRC_URI = "git://github.com/tensorflow/estimator.git;branch=r2.4 \
+ file://0001-customize-for-yocto.patch \
"
-SRCREV = "340703eed78ba4854862f749ed94f91598826e79"
+SRCREV = "c3e7f2b5bbcc35185ef71797955a28cadce28f60"
S = "${WORKDIR}/git"

inherit python3native bazel
@@ -19,12 +20,18 @@ DEPENDS += " \
python3-astor-native \
python3-gast-native \
python3-termcolor-native \
+ python3-wrapt-native \
+ python3-opt-einsum-native \
+ python3-astunparse-native \
+ flatbuffers-native \
I'm getting issue when building tensorflow-estimator (I add small
changes to be able to build this patches on top of dunfell) and I'm
getting:
| /bin/bash -c 'source
external/bazel_tools/tools/genrule/genrule-setup.sh;
bazel-out/k8-opt-exec-2B5CBBC6/bin/tensorflow_estimator/python/estimator/api/create_tensorflow_estimator.python.estimator_api_1_estimator_python_api_gen_compat_v1
--apidir=bazel-out/k8-fastbuild/bin/tensorflow_estimator/python/estimator/api_v1/
--apiname=estimator --apiversion=1
--package=tensorflow_estimator.python.estimator
--output_package=tensorflow_estimator.python.estimator.api._v1
bazel-out/k8-fastbuild/bin/tensorflow_estimator/python/estimator/api/_v1/v1.py
bazel-out/k8-fastbuild/bin/tensorflow_estimator/python/estimator/api/_v1/estimator/__init__.py
bazel-out/k8-fastbuild/bin/tensorflow_estimator/python/estimator/api/_v1/estimator/experimental/__init__.py
bazel-out/k8-fastbuild/bin/tensorflow_estimator/python/estimator/api/_v1/estimator/export/__init__.py
bazel-out/k8-fastbuild/bin/tensorflow_estimator/python/estimator/api/_v1/estimator/inputs/__init__.py
bazel-out/k8-fastbuild/bin/tensorflow_estimator/python/estimator/api/_v1/estimator/tpu/__init__.py
bazel-out/k8-fastbuild/bin/tensorflow_estimator/python/estimator/api/_v1/estimator/tpu/experimental/__init__.py')
| Execution platform: @local_config_platform//:host
| /home/ubuntu/projects/test/build/tmp/work/aarch64-poky-linux/tensorflow-estimator/2.4-r0/recipe-sysroot-native/usr/lib/python3.8/site-packages/h5py/__init__.py:72:
UserWarning: h5py is running against HDF5 1.8.21 when it was built
against 1.8.19, this may cause problems
| _warn(("h5py is running against HDF5 {0} when it was built against {1}, "
| Traceback (most recent call last):
| File "/home/ubuntu/projects/test/build/tmp/work/aarch64-poky-linux/tensorflow-estimator/2.4-r0/bazel/output_base/execroot/org_tensorflow_estimator/bazel-out/k8-opt-exec-2B5CBBC6/bin/tensorflow_estimator/python/estimator/api/create_tensorflow_estimator.python.estimator_api_1_estimator_python_api_gen_compat_v1.runfiles/org_tensorflow_estimator/tensorflow_estimator/python/estimator/api/create_python_api_wrapper.py",
line 26, in <module>
| from tensorflow_estimator.python.estimator import estimator_lib
# pylint: disable=unused-import
| File "/home/ubuntu/projects/test/build/tmp/work/aarch64-poky-linux/tensorflow-estimator/2.4-r0/bazel/output_base/execroot/org_tensorflow_estimator/bazel-out/k8-opt-exec-2B5CBBC6/bin/tensorflow_estimator/python/estimator/api/create_tensorflow_estimator.python.estimator_api_1_estimator_python_api_gen_compat_v1.runfiles/org_tensorflow_estimator/tensorflow_estimator/python/estimator/estimator_lib.py",
line 22, in <module>
| from tensorflow_estimator.python.estimator.canned.baseline
import BaselineClassifier
| File "/home/ubuntu/projects/test/build/tmp/work/aarch64-poky-linux/tensorflow-estimator/2.4-r0/bazel/output_base/execroot/org_tensorflow_estimator/bazel-out/k8-opt-exec-2B5CBBC6/bin/tensorflow_estimator/python/estimator/api/create_tensorflow_estimator.python.estimator_api_1_estimator_python_api_gen_compat_v1.runfiles/org_tensorflow_estimator/tensorflow_estimator/python/estimator/canned/baseline.py",
line 53, in <module>
| import tensorflow as tf
| File "/home/ubuntu/projects/test/build/tmp/work/aarch64-poky-linux/tensorflow-estimator/2.4-r0/recipe-sysroot-native/usr/lib/python3.8/site-packages/tensorflow/__init__.py",
line 55, in <module>
| from ._api.v2 import compat
| File "/home/ubuntu/projects/test/build/tmp/work/aarch64-poky-linux/tensorflow-estimator/2.4-r0/recipe-sysroot-native/usr/lib/python3.8/site-packages/tensorflow/_api/v2/compat/__init__.py",
line 39, in <module>
| from . import v1
| File "/home/ubuntu/projects/test/build/tmp/work/aarch64-poky-linux/tensorflow-estimator/2.4-r0/recipe-sysroot-native/usr/lib/python3.8/site-packages/tensorflow/_api/v2/compat/v1/__init__.py",
line 34, in <module>
| from . import compat
| File "/home/ubuntu/projects/test/build/tmp/work/aarch64-poky-linux/tensorflow-estimator/2.4-r0/recipe-sysroot-native/usr/lib/python3.8/site-packages/tensorflow/_api/v2/compat/v1/compat/__init__.py",
line 39, in <module>
| from . import v1
| File "/home/ubuntu/projects/test/build/tmp/work/aarch64-poky-linux/tensorflow-estimator/2.4-r0/recipe-sysroot-native/usr/lib/python3.8/site-packages/tensorflow/_api/v2/compat/v1/compat/v1/__init__.py",
line 51, in <module>
| from tensorflow._api.v2.compat.v1 import lite
| File "/home/ubuntu/projects/test/build/tmp/work/aarch64-poky-linux/tensorflow-estimator/2.4-r0/recipe-sysroot-native/usr/lib/python3.8/site-packages/tensorflow/_api/v2/compat/v1/lite/__init__.py",
line 11, in <module>
| from . import experimental
| File "/home/ubuntu/projects/test/build/tmp/work/aarch64-poky-linux/tensorflow-estimator/2.4-r0/recipe-sysroot-native/usr/lib/python3.8/site-packages/tensorflow/_api/v2/compat/v1/lite/experimental/__init__.py",
line 10, in <module>
| from . import nn
| File "/home/ubuntu/projects/test/build/tmp/work/aarch64-poky-linux/tensorflow-estimator/2.4-r0/recipe-sysroot-native/usr/lib/python3.8/site-packages/tensorflow/_api/v2/compat/v1/lite/experimental/nn/__init__.py",
line 10, in <module>
| from tensorflow.lite.python.lite import TFLiteLSTMCell
| File "/home/ubuntu/projects/test/build/tmp/work/aarch64-poky-linux/tensorflow-estimator/2.4-r0/recipe-sysroot-native/usr/lib/python3.8/site-packages/tensorflow/lite/python/lite.py",
line 40, in <module>
| from tensorflow.lite.python.convert import
build_toco_convert_protos # pylint: disable=unused-import
| File "/home/ubuntu/projects/test/build/tmp/work/aarch64-poky-linux/tensorflow-estimator/2.4-r0/recipe-sysroot-native/usr/lib/python3.8/site-packages/tensorflow/lite/python/convert.py",
line 33, in <module>
| from tensorflow.lite.python import util
| File "/home/ubuntu/projects/test/build/tmp/work/aarch64-poky-linux/tensorflow-estimator/2.4-r0/recipe-sysroot-native/usr/lib/python3.8/site-packages/tensorflow/lite/python/util.py",
line 30, in <module>
| import flatbuffers
| ModuleNotFoundError: No module named 'flatbuffers'

FLatbuffers from openembedded are available version 1.12. Do you have
an idea what is can cause?
tensorflow-native \
"

do_compile () {
unset CC
export TMPDIR="${WORKDIR}"
+ export PYTHON_BIN_PATH="${PYTHON}"
+
${BAZEL} build \
--subcommands --explain=${T}/explain.log \
--verbose_explanations --verbose_failures \
@@ -32,7 +39,6 @@ do_compile () {
--python_path="${PYTHON}" \
//tensorflow_estimator/tools/pip_package:build_pip_package

- PYTHON_BIN_PATH="${PYTHON}" \
${S}/bazel-bin/tensorflow_estimator/tools/pip_package/build_pip_package \
${WORKDIR}/estimator_pip
}
--
2.21.0
Thanks and BR,

marek
--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com


#yocto #gstreamer #gstreamer1.0-plugins-bad #yocto #gstreamer #aom #av1

safouane maaloul
 

Bonjour, j'essaye d'ajouter le aom plugin au niveau de la gstreamer1.0-plugins-bad. J'ai basculé sur gatesgarth version. Je commence à faire lebuild. J'avais un problème de lisence. Je l'ai résolu. Et maintenant j'ai un problème "no such file or directory automake-native yocto" et j'arrive pas à la résoudre ? Est-ce que vous pouvez m'aider ? y a t il quelqu'un qui a essayé d'ajouter av1 codec (aom plugins/gstreamer1.0-plugins-bad).

Cordialement,

Safouane.Maaloul


Re: Standard library header bug when compiling x32 application

Paul D. DeRocco
 

From: Paul D. DeRocco

Using Yocto 3.2.1 on an Intel target, trying to use the x32 model. I'm
getting this compile error when I use the SDK to separately compile my
application. I get no such errors when I build Linux, or the SDK.

In file included from
/opt/poky/3.2.1/i64/sysroots/core2-64-poky-linux/usr/include/sys/cdefs.h:453
,
from
/opt/poky/3.2.1/i64/sysroots/core2-64-poky-linux/usr/include/features.h:465,
from
/opt/poky/3.2.1/i64/sysroots/core2-64-poky-linux/usr/include/dirent.h:25,
from ../my_header_file.h:7,
from ../my_source_file.cpp:3:
/opt/poky/3.2.1/i64/sysroots/core2-64-poky-linux/usr/include/bits/long-doubl
e.h:23:10: fatal error: bits/long-double-32.h: No such file
or directory
etc., etc.

I solved this myself by building an SDK specific to the x32 configuration,
rather than trying to use the plain 64-bit SDK. What led me to believe that
the 64-bit SDK should work is that the host sysroot includes
/usr/bin/x86_64-poky-linux and /usr/bin/x86_64-poky-linux-gnux32
subdirectories. The latter contains symlinks into the former, which is no
surprise, since one toolchain should be able to do 32, 64, and 64x32, but
the target sysroot include files don't quite work. The only reason I care is
that each SDK is about 2.4GB. So I'm not sure if this is a bug, or whose bug
it is, but 2.4GB seems awfully large for an SDK, especially since this is
the standard SDK, not the ESDK.

--

Ciao, Paul D. DeRocco
Paul mailto:pderocco@ix.netcom.com


How do I build an x32 Intel system?

Paul D. DeRocco
 

I've been resurrecting an old Pyro project under Gatesgarth. It's an Intel
32-bit system that needs maximum speed, so I decided to try to build the
system and application as 64-bit, for more registers. It pretty much worked
on the first try, and is about 8% faster. Now I'm trying to do it as x32, to
see if that speeds it up even more.

Unable to find any specific instructions, I set the DEFAULTTUNE to
"core2-64-x32" in my BSP conf file. Also, in the old project I had tinkered
around with this a bit, and had found some kernel config settings somewhere,
so I tried using them again:

CONFIG_X86_X32=y
CONFIG_COMPAT=y
CONFIG_COMPAT_FOR_U64_ALIGNMENT=y
CONFIG_SYSVIPC_COMPAT=y
CONFIG_KEYS_COMPAT=y
CONFIG_HAVE_ARCH_MMAP_RND_COMPAT_BITS=y
CONFIG_ARCH_MMAP_RND_COMPAT_BITS=8
CONFIG_BLOCK_COMPAT=y

Other than the first one, I don't know whether these are correct, or where I
originally got them, or if there's a stock .cfg file that does all this.

The system built fine, the SDK built fine, and my application built fine,
but when I boot, I get a kernel panic, preceded by some message about "kmod
busy with 50 threads for more than 5 seconds now".

Is there some instruction on how to do a proper x32 build? I couldn't find
one Googling. Barring that, do any of those kernel configs look bogus?

--

Ciao, Paul D. DeRocco
Paul mailto:pderocco@ix.netcom.com


Standard library header bug when compiling x32 application

Paul D. DeRocco
 

Using Yocto 3.2.1 on an Intel target, trying to use the x32 model. I'm
getting this compile error when I use the SDK to separately compile my
application. I get no such errors when I build Linux, or the SDK.

In file included from
/opt/poky/3.2.1/i64/sysroots/core2-64-poky-linux/usr/include/sys/cdefs.h:453
,
from
/opt/poky/3.2.1/i64/sysroots/core2-64-poky-linux/usr/include/features.h:465,
from
/opt/poky/3.2.1/i64/sysroots/core2-64-poky-linux/usr/include/dirent.h:25,
from ../my_header_file.h:7,
from ../my_source_file.cpp:3:
/opt/poky/3.2.1/i64/sysroots/core2-64-poky-linux/usr/include/bits/long-doubl
e.h:23:10: fatal error: bits/long-double-32.h: No such file or directory

long-double.h includes either long-double-32.h or long-double-64.h based on
the __WORDSIZE macro, which is 32. This works fine when compiling straight
32-bit or 64-bit code, but fails in x32 code because only long-double-64.h
exists. I don't see why the characteristics of a long double should have
anything to do with the "word size" of a pointer or long int. And indeed,
the two headers it chooses from are basically empty, except for defining
__LDOUBLE_REDIRECTS_TO_FLOAT128_ABI. I'm also not sure why it would be
harmful for both of these files to exist always.

So this is an obvious bug. But my question is: what's the cleanest way to
get over this hump? Patch cdefs.h when building the SDK? Use a bbappend on
some SDK recipe to copy long-double-64.h to long-double-32.h? I have no idea
where this recipe would be.

--

Ciao, Paul D. DeRocco
Paul mailto:pderocco@ix.netcom.com


Re: Making partitions in .hddimg image

Howard
 

Hi Nikhil:

I searched for a solution to this for a very long time.  I never did find a solution.  However I also learned I really did not need this for my .hddimg.  

For early development booting from a USB stick, I simply used a WIC image partitioned in the way that I wanted my target's flash to be partitioned.   I referenced this thread for the clues I needed to create the partitions I needed on the wic image.

https://stackoverflow.com/questions/56187209/yocto-create-and-populate-a-separate-home-partition

Of course on the WIC boot menu, there is no install option, so that doesn't quite get you to a standalone target running from internal storage.

Then I figured out that if I only use the .hddimage for installation to internal storage rather than for operation, you can modify (by using a bbappend) the installation script to create the partitions you want during installation.  

For us that script was located at meta/recipes-core/initrdscripts/files/init-install-efi.sh .  Its actually unusually well commented so you can probably follow along after a few re-reads and understand what it is doing.  

Getting a software update scheme working (that's a whole other subject) while you are still working on the wic image will allow you to basically install from the .hddimg once (or whenever you trash your target drive :) ) and then use your update scheme to install a new image, and skip the USB stick step altogether.

Sorry to be so wordy, but hope this helps.
Howard


Re: chpasswd not working in yocto-2019

Raghu Icecraft Software Trainings
 

Hello,
Thanks for the reply.
I mailed to 
meta-xilinx@...
But no response yet, can you please let me know where else can i find some information.

Thanks,
Raghu

On Mon, Dec 28, 2020 at 7:28 PM Philip Balister <philip@...> wrote:
On 12/28/20 7:33 AM, Raghu Icecraft Software Trainings wrote:
> Paul,
> Thanks for the reply.
> I am using Xilinx-SDK based : Linux version 4.19.0-rt1-xilinx-v2019.1
>
> Can you please let me know how to verify the yocto version running on
> target.

You might have better luck on the meta-xilinx mailing list. They should
know the details for their BSP.

More info on Xilnx layers and a pointer to subscribe info to the mailing
list is here:

https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841883/Yocto

Philip

>
> Thanks,
> Raghu
>
> On Mon, Dec 28, 2020 at 5:31 PM Paul Barker <pbarker@...> wrote:
>
>> On Mon, 28 Dec 2020 at 09:44, Raghu Icecraft Software Trainings
>> <raghu.icecraft@...> wrote:
>>>
>>> Hello,
>>> I have upgraded my kernel poky to 2019.1 version, here i am unable to
>> find chpasswd utility because of which i am unable to set password to my
>> root-user.
>>> Can you please let me know if the chpasswd utility has been changed or
>> modified please.
>>
>> Yocto Project doesn't have a version "2019.1", see
>> https://wiki.yoctoproject.org/wiki/Releases.
>>
>> I guess you're using a vendor supplied BSP or SDK with that version
>> number. Could you provide the Yocto Project version number and the
>> layers in use, or at least give some more info on where your "2019.1"
>> release is from.
>>
>> Thanks,
>>
>> --
>> Paul Barker
>> Konsulko Group
>>
>
>
>
>
>


Re: Need to disable IPV6 completely from the yocto image for Raspberrypi

md.sadiq@...
 

Hi,

To remove completely ipv6 from distro disable all the kernel configurations related to ipv6, add the the below line in the local.conf file
DISTRO_FEATURES_remove = "ipv6".

If above doesnot help create your own distro file owndistro.conf and add below lines to remove unwanted features as follows

DISTRO_FEATURES_remove = " ipv6 x11 wayland"

and change local.conf as follows

DISTRO ?= "owndistro"



Regards,
Sadiq


Re: Help regarding yocto receipe (bluez5)

chandra naik <chandumail05@...>
 

Hi

can we get obexpush open source package for yocto build ? we are not able to find . kernel version - 4.14 DISTRO_VERSION = "2.5.1"


On Tue, Dec 29, 2020 at 3:40 PM Konrad Weihmann <kweihmann@...> wrote:
I would recommend that you go for a systemd drop-in file [1].
That would be something like a small snippet placed to
/etc/systemd/system/dbus-org.bluez.service/override.conf

In that file place something like
[Service]
ExecStart=
ExecStart=<new command line with your custom options>

this way you don't need to alter the upstream recipe with weird sed
hacks or similar.

This drop-in file could be packaged by any recipe or bbappend.

[1] https://coreos.com/os/docs/latest/using-systemd-drop-in-units.html

On 29.12.20 07:48, chandra naik wrote:
> Hi
>
> After board boot up , we are editing vi
> /etc/systemd/system/dbus-org.bluez.service these file as
> ExecStart=/usr/lib/bluetooth/bluetoothd -C (here we are adding -C means
> bluetooth running in compact mode).
>
> but these is not good practice , so how we can change these service at
> compiling time itself , any idea ? main agenda is Run bluetoothd daemon
> in compatibility mode while building yocto image.
>
>
>
>


Issue regarding with .wic image

chandra naik <chandumail05@...>
 

Hi ,
we are a .wic (production image) image for ostree , in these core-image-sato.wic image everything is read only , Here when i am trying to edit something it will show file is readonly. so how we can edit a file or service in .wic image ?


#yocto #gstreamer #gstreamer1.0-plugins-bad #yocto #gstreamer #aom #av1

safouane maaloul
 

Bonjour, j'essaye d'ajouter le aom plugin au niveau de la gstreamer1.0-plugins-bad. J'ai basculé sur gatesgarth version. Je commence à faire lebuild. J'avais un problème de lisence. Je l'ai résolu. Et maintenant j'ai un problème "no such file or directory automake-native yocto" et j'arrive pas à la résoudre ? Est-ce que vous pouvez m'aider ?
 
Cordialement,
 
Safouane.Maalou


Making partitions in .hddimg image

NIKHIL PATIL
 

Hi,
   For .wic image partiotions ( EFI , OTAROOT ) are already created  likewise ; How to create a partiotions in core-image-intel.hddimg image  ? in .hddimg only one partition ( boot ) is there .
 



Re: quit-native issue #yocto

Michael Nazzareno Trimarchi
 

Hi



On Wed, Dec 30, 2020, 7:46 AM sateesh m <sateesh0457@...> wrote:
Hi Guys,

        I am trying to build core-image-sato using dunfell sources. i am facing bug quilt-native configure issue. its present in meta/recipes-devtools.

Below i am attaching  my issue odt file. can please check it . help me to solve this issue.

mktemp -d seems to fail so you could have a broken permission on your temp directory

Can you run it manually?

Michael




quit-native issue #yocto

sateesh m
 

Hi Guys,

        I am trying to build core-image-sato using dunfell sources. i am facing bug quilt-native configure issue. its present in meta/recipes-devtools.

Below i am attaching  my issue odt file. can please check it . help me to solve this issue.


What to do when a patch isn't needed?

Paul D. DeRocco
 

I'm upgrading a project from Pyro to Gatesgarth. Building the toolchain, it
barfs on a patch which isn't needed. Here's one of the error messages:

ERROR: binutils-native-2.35-r0 do_patch: Command Error: 'quilt --quiltrc
/home/pauld/yocto-gatesgarth/build-intel32/tmp/work/x86_64-linux/binutils-na
tive/2.35-r0/recipe-sysroot-native/etc/quiltrc push' exited with 0 Output:
Applying patch gas_as.h.patch
patching file gas/as.h
Hunk #1 FAILED at 486.
1 out of 1 hunk FAILED -- rejects in file gas/as.h
Patch gas_as.h.patch can be reverse-applied

There are two more just like it, for the cross and target versions. All it
is is a patch to add one external function definition, but it's already
there.

Is there a preferred way to fix this with a bbappend? Perhaps replacing the
patch file with an empty one?

--

Ciao, Paul D. DeRocco
Paul mailto:pderocco@ix.netcom.com


Re: Prevent WIC image from being built?

Robert P. J. Day
 

On Tue, 29 Dec 2020, Howard wrote:

Yup, thank you Bruce:

Using
IMAGE_FSTYPES_remove += "wic"

Didn't do it for me, but

IMAGE_TYPES_remove += "wic"

did the trick. 
pedantry, but i'm fairly sure "=" would have sufficed; there was no
need to use "+=" here.

rday

2021 - 2040 of 53871