|
Current high bug count owners for Yocto Project 3.3
Stephen Jolley
All,
Thanks,
Stephen K. Jolley Yocto Project Program Manager ( Cell: (208) 244-4460 * Email: sjolley.yp.pm@...
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Yocto Project Newcomer & Unassigned Bugs - Help Needed
Stephen Jolley
All,
The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on the triage page under the appropriate heading: https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs Also please review: https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and how to create a bugzilla account at: https://bugzilla.yoctoproject.org/createaccount.cgi The idea is these bugs should be straight forward for a person to help work on who doesn't have deep experience with the project. If anyone can help, please take ownership of the bug and send patches! If anyone needs help/advice there are people on irc who can likely do so, or some of the more experienced contributors will likely be happy to help too.
Also, the triage team meets weekly and does its best to handle the bugs reported into the Bugzilla. The number of people attending that meeting has fallen, as have the number of people available to help fix bugs. One of the things we hear users report is they don't know how to help. We (the triage team) are therefore going to start reporting out the currently 345 unassigned or newcomer bugs.
We're hoping people may be able to spare some time now and again to help out with these. Bugs are split into two types, "true bugs" where things don't work as they should and "enhancements" which are features we'd want to add to the system. There are also roughly four different "priority" classes right now, “3.2”, “3.3, "3.99" and "Future", the more pressing/urgent issues being in "3.2" and then “3.3”.
Please review this link and if a bug is something you would be able to help with either take ownership of the bug, or send me (sjolley.yp.pm@...) an e-mail with the bug number you would like and I will assign it to you (please make sure you have a Bugzilla account). The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer_Bugs
Thanks,
Stephen K. Jolley Yocto Project Program Manager ( Cell: (208) 244-4460 * Email: sjolley.yp.pm@...
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Reminder: Yocto Project Technical Team Meeting @ Monthly from 8am on the first Tuesday (PDT)
Stephen Jolley
All,
Just a reminder we will hold the monthly Yocto Project Technical Meeting at 8am PST tomorrow. (1/5)
Yocto Project Technical Team Meeting: We encourage people attending the meeting to logon and announce themselves on the Yocto Project IRC chancel during the meeting (optional): Yocto IRC: http://webchat.freenode.net/?channels=#yocto
Wiki: https://www.yoctoproject.org/public-virtual-meetings/
When Monthly from 8am to 9am on the first Tuesday Pacific Time Where Zoom Meeting: https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09
We are tracking the minutes at: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit?pli=1 Please request access if you want to assist in editing them. The world should have view access.
Thanks,
Stephen K. Jolley Yocto Project Program Manager ( Cell: (208) 244-4460 * Email: sjolley.yp.pm@...
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: oeqa: test cases at the end of the test suite
Ross Burton <ross@...>
On Mon, 4 Jan 2021 at 10:50, Konrad Weihmann <kweihmann@...> wrote:
I have a few oeqa test cases, which always should run last in a testThose are not test cases then, surely. If you want to run actions after test cases to collect log files then I'd implement that as a decorator on the test cases. Ross
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
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,
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: How do I build an x32 Intel system?
Morgan Hill
Other than the first one, I don't know whether these are correct, orI'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+> <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 <kweihmann@...>
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 <kweihmann@...>
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@...> wrote: 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 \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/opt/poky/3.2.1/i64/sysroots/core2-64-poky-linux/usr/include/sys/cdefs.h:453 ,/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/bits/long-doubl e.h:23:10: fatal error: bits/long-double-32.h: No such fileetc., 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@...
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
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@...
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
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@...
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
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
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:
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
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].
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
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 <nikhilvp29@...>
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 .
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||