Re: [yocto] EXTRA_USERS_PARAMS and recipe file ownership
On Fri, Apr 19, 2024 at 7:29 AM Maik Vermeulen via lists.yoctoproject.org wrote: %< SNIP %< > I've also tried using the useradd.bbclass in the recipes, which allows us > to set permissions from within the do_install task, but that started > causing trouble when we tried to start using useradd-staticids, which we > need to keep compatibility between software versions using the same files > from a persistent partition. The useradd.bbclass in combination with the > central extrausers.bbclass and useradd-staticids.bbclass is messy and > hasn't resulted in a working build yet, with recipes complaining certain > groups e.g. aren't available yet. > You are not very specific about what is going wrong, but it sounds familiar so it is possible that I am to blame for not following up on an earlier observation that may potentially benefit your situation. Take a look at this message and let me know if it sounds familiar. https://lists.openembedded.org/g/openembedded-core/topic/88922422#161387 If so I can probably submit an RFC patch. ..Ch:W.. -- *"Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire* -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#62971): https://lists.yoctoproject.org/g/yocto/message/62971 Mute This Topic: https://lists.yoctoproject.org/mt/105618946/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] #bitbake - Single Recpie Multiple Outputs/Build Types
On Mon, Dec 4, 2023 at 11:46 AM Eric Guinn via lists.yoctoproject.org wrote: > Hello, > > I need some feedback/advice on a "problem" I'm facing with the recipe > system. Currently, I have a library written in C++ that also has generated > SWIG bindings and a resultant Python lib to install. In order to do both > the C++ build/install and the python build/install I have to use two > different recipes, but really these outputs always need to be present > together (they're in the same repo). I may also add .NET bindings in the > future, so any answers related to that will help as well. > > Insofar I've not found a way to get a single recipe to do multiple > builds/installs, if I do: > > ``` > inherit cmake > inherit setuptools3 > ``` > Probably not ideal, but perhaps you could roll the entire build (C++ and Python) into your CMakeLists.txt file and use your recipe to generate separate packages? ..Ch:W.. -- *"Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire* -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#61798): https://lists.yoctoproject.org/g/yocto/message/61798 Mute This Topic: https://lists.yoctoproject.org/mt/102977917/21656 Mute #bitbake:https://lists.yoctoproject.org/g/yocto/mutehashtag/bitbake Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] FireFox
On Wed, Dec 21, 2022 at 12:39 AM wrote: %< SNIP %< *6. After I start my machine and enter firefox in command line this error > occurs: no DISPLAY environment variable specified* > > The DISPLAY variable is the host that is running the X server that will display your Firefox window. Since you said you are running the image as a virtual machine in VirtualBox, then you probably mean to have an X server running on your host machine that can display the windows exported by your virtual machine. ..Ch:W.. -- *"Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire* -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58852): https://lists.yoctoproject.org/g/yocto/message/58852 Mute This Topic: https://lists.yoctoproject.org/mt/95802925/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Yocto with Monorepo - best practice for building apps that have source within the repo?
On Wed, Dec 14, 2022 at 11:19 AM David Antliff wrote: > How do you handle that in Yocto though? What mechanisms do you use to > refer to your code? Do you just keep it all under the files/ directories? > Sorry for the slow reply. Yes, keeping it under the recipe is the approach we use. For example... yocto └── meta-abc └── recipes-xyz └── helloworld ├── files │ ├── LICENSE │ └── src │ ├── Makefile │ └── helloworld.c └── helloworld.bb Your bitbake recipe would be fairly straightforward. The only difficulty is in doing IDE driven development without seeing a sea of red if your project is broken up into a lot of dependencies managed by separate recipes. There are ways of resolving that as well with a lot of pros and cons depending on how your project works. ..Ch:W.. -- *"Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire* -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58850): https://lists.yoctoproject.org/g/yocto/message/58850 Mute This Topic: https://lists.yoctoproject.org/mt/95654029/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Yocto with Monorepo - best practice for building apps that have source within the repo?
On Wed, Dec 14, 2022 at 1:40 AM Alexander Kanavin wrote: > On Wed, 14 Dec 2022 at 10:34, David Antliff wrote: > > Good question! I would prefer not to use a monorepo but it has been > imposed on me. It predates my involvement and I’m stuck with it, > unfortunately. Consider it an unavoidable constraint. There's a lot in the > repo, and the yocto project is just one part of it. > > > > Frankly it would make my life a lot easier if I didn't have to work with > a monorepo, but my leaders insist that it makes things "easier"... > What reasons do they give for that assertion? Let me guess: they heard that facebook is using a monorepo, so that > makes it a 'best practice'? > One size definitely does not suit all. Distro builds that coalesce code from a lot of different internal dev teams are going to have a tough time with the mono-repo approach. Conversely, a team that controls all of its application layer code is going to have a difficult time with a distributed repo approach. So... best practice? Best practice should be to do what makes the most sense for your particular situation. I manage an embedded build that includes a non-trivial number of in-house developed source trees maintained by a single team. All of this code has no life outside of embedded builds. Managing that in a distributed repo fashion is a terrible idea for more reasons than I have time to describe. Collecting the source into relevant meta-layers coalesced the work down to a much more manageable problem. ..Ch:W.. -- *"Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire* -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58801): https://lists.yoctoproject.org/g/yocto/message/58801 Mute This Topic: https://lists.yoctoproject.org/mt/95654029/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] How to remove shared libraries dependencies?
On Sun, Oct 30, 2022 at 6:34 PM Priyanshu Sharma < ms.priyanshu.sha...@gmail.com> wrote: > I've a requirement in which I want to package veritysetup binary in a > minimal filesystem (which is size constraint) > Including "cryptsetup" package in IMAGE_INSTALL is adding the binary but > also a lot of shared libraries which are its dependencies. The shared > libraries are increasing the size of the filesystem, which should not be > done. I do not need functionalities like ssl for veritysetup, so how can I > remove the dependencies on these shared libraries? > > I've tried removing eg ssl from > https://git.openembedded.org/meta-openembedded/tree/meta-oe/recipes-crypto/cryptsetup/cryptsetup_2.4.3.bb#n29 > but > the shared libs are still the dependency. > It sounds like you are trying to build a runtime overlay package that omits all dependencies. If so, this might help. https://lore.kernel.org/all/CAB=6tbrryhurrgqwgwby_h5dbr8euxijtemvvarbtotnzdb...@mail.gmail.com/ ..Ch:W.. -- *"Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire* -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58446): https://lists.yoctoproject.org/g/yocto/message/58446 Mute This Topic: https://lists.yoctoproject.org/mt/94676916/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Fixing [host-user-contaminated] warning
On Sun, Oct 16, 2022 at 12:13 PM wrote: %< SNIP %< > I tried various options of tar to extract these files with different UID > and GID with no success. > How can I solve this issue? I think it would be better if I patch the > script to use the install command but I am not sure how can I integrate > that kind of workflow with lots of tar archives that includes lots of > subdirectories. > You were unclear about which tar options you tried, so it makes me wonder if you tried --no-same-owner. I use that in a number of places in my builds and it works just fine. ..Ch:W.. -- *"Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire* -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58343): https://lists.yoctoproject.org/g/yocto/message/58343 Mute This Topic: https://lists.yoctoproject.org/mt/94369702/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Force binary package install
> >> Is there an elegant way around it? >> >> >> >> >> >> Error: >> >>Problem: conflicting requests >> >> - nothing provides libdl.so.2 needed by >> >> xxx-single-group-0.1-r0.cortexa53_crypto >> >> - nothing provides libdl.so.2(GLIBC_2.0) needed by >> > Could this be considered a bug in the package_rpm.bbclass? It seems to me that if you skip files-rdeps, we might not want to be adding anything into splitpreinst. Otherwise it seems silly to tell insane.bbclass to skip something that RPM is going to ding you on later anyway. Or maybe I am confused... In any case, I believe what you may be seeing can be viewed as an RPM-ism, and not necessarily a yocto-ism per se. So you might consider trying one of the following to work around the problem: Experiment with using a virtual provider. It may be possible to just map the dependency manually to what is already there. If you _know_ that your dependency is truly isolated to your recipe, you may be able to set RPROVIDES values in your recipe so the resulting RPM thinks the dependencies are met internally. Patch package_rpm.bbclass to add a guard variable around the setting of splitpreinst. Add that guard variable to your recipe so it selectively turns off the pre-install checks for that particular package. Or just check for files-rdeps in INSANE_SKIP and do the same thing... Stop fighting RPM and switch to a different package type like IPK. ..Ch:W.. -- *"Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire* -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#57301): https://lists.yoctoproject.org/g/yocto/message/57301 Mute This Topic: https://lists.yoctoproject.org/mt/91607892/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] SSTATE corruption
Alex is very much correct, you should not see corruption. But I think more detail is in order. If your distro repository is a "garden variety" set of image recipes and recipe overrides that pull upstream source bundles, then your SSTATE cache should age nicely from release to release. However, if your source code and associated application files ride along in the same repository as your recipes, or you add your own bbclass functionality, you may want to reconsider keeping SSTATE cache around for too long. There are still some issues to be worked out to make the local file fetcher as reliable as the other fetchers when it comes to keeping your distro buttoned up into one monolithic repository with application level source code trees. ..Ch:W.. On Tue, Mar 22, 2022 at 7:13 AM Alexander Kanavin wrote: > No and no. > > Alex > > On Tue, 22 Mar 2022 at 14:48, Rusty Howell wrote: > > > > Is the sstate cache sensitive to different releases and or the ordering > of the bblayers? We are upgrading our Yocto-based distro from dunfell to > hardknott. So for a while we will be building our distro on both > releases. Do we need to keep the sstate caches separate for these builds? > > > > Another related question... Does changing the order of the bblayers > corrupt the sstate cache (ie require a fresh sstate)? > > Thanks > > > > > > > > > > -- *"Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire* -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#56533): https://lists.yoctoproject.org/g/yocto/message/56533 Mute This Topic: https://lists.yoctoproject.org/mt/89952176/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Honister on Ubuntu 14.04
On Thu, Mar 3, 2022 at 10:07 AM Daniel Ammann wrote: > I'm trying to build honister on Ubuntu 14.04. This is meant as a temporary > solution until the build server can be upgraded to something recent. > For now, I got it running with extended buildtools from poky, but the > build of > libnsl2-native fails. It appears that the pkgconfig step is not executed > properly since do_compile fails with a header not found error. > > Has anybody done a successful build of honister on Ubuntu 14.04? Is it even > possible? > I cannot speak for Honister, but I can speak to the higher level abstraction that is causing you issues. The solution is to copy the (right version of the) missing header file into the proper location in the buildtools directory. I maintain a running list of things I have to add to buildtools that I have posted to this list in the past. ..Ch:W.. -- *"Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire* -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#56378): https://lists.yoctoproject.org/g/yocto/message/56378 Mute This Topic: https://lists.yoctoproject.org/mt/89531212/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] run.do_compile error on poky-dunfell release
Just replace the word "commit" in the URL with the word patch, like so: https://git.kernel.org/pub/scm/linux/kernel/git/legion/kbd.git/patch/?id=50eae66fc21ef8e01c69a9d3c1ff3fcb0b2644a0 ..Ch:W.. On Tue, Feb 8, 2022 at 9:46 AM Sourabh Hegde wrote: > Hello Khem, > > Thanks for quick response. > > Can you please let me know where to include this patch file? > > Thanks in advance. > > > -- *"Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire* -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#56109): https://lists.yoctoproject.org/g/yocto/message/56109 Mute This Topic: https://lists.yoctoproject.org/mt/88998953/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [OE-core] Inclusive Language Proposal for YP/OE
On Mon, Jan 24, 2022 at 8:18 AM Jon Mason wrote: %< SNIP %< > Branch Names > The “master” branches on the relevant OpenEmbedded and Yocto Project > git trees will be changed to an alternative name at some point in the > future. The current preferred name is “devel”. > Why devel instead of main [1]? [1] https://lore.kernel.org/git/pull.656.v4.git.1593009996.gitgitgad...@gmail.com/ ..Ch:W.. -- *"Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire* -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#55963): https://lists.yoctoproject.org/g/yocto/message/55963 Mute This Topic: https://lists.yoctoproject.org/mt/88674413/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] SRC_URI Directory Change
On Fri, Oct 15, 2021 at 6:58 AM Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:
>
> I have a bit of a horrible idea to do this in master-next which does solve
> the
> problem. We probably need a new bitbake selftest testcase before I could
> think
> about merging it though.
>
I tested the patch you posted on IRC against bitbake 1.50.0. It seems to
work
quite well, but I think I found two minor bugs in it. I pasted an updated
patch below.
In a nutshell...
If you have a SRC_URI file:// entry that ends in a "/", then you get a "."
that is
not enclosed in "/./" when running the checksum_dir method, which causes
checksum_file to throw warnings that look like this:
WARNING: Unable to get checksum for gettext-minimal-native SRC_URI entry
.intlmacosx.m4: [Errno 2] No such file or directory:
'/mnt/openembedded-core/meta/recipes-core/gettext/gettext-minimal-0.21/aclocal/.intlmacosx.m4'
I think the simplest fix is to add a "pth = pth.rstrip("/")" in the
checksum_dir method after
the guard statement. But then that exposes a different issue in the patch.
For recipes that trigger the above warning, the rstrip() fix fixes the
warning, but then you
expose a new problem in siggen.py calc_taskhash().
In your patched version, the check for the "/" fails to include the
filename in the hash calculation
for files at the root of a SRC_URI entry (there is no "/" to be found).
This results in a task hash
mismatch error on the first build, but not on subsequent builds for fairly
obvious reasons.
I solved this by adding a third field to the tuple with a True/False value,
which is a much more reliable semaphore (IMHO).
I tested these fixes and it worked perfectly. Here is an updated version of
your patch that takes into
account the fixes I described. I can produce a "patch against your patch"
if these fixes are
considered correct and do not cause even bigger problems that are not
obvious to me.
diff --git a/bitbake/lib/bb/checksum.py b/bitbake/lib/bb/checksum.py
index 1d50a26426..fb8a77f6ab 100644
--- a/bitbake/lib/bb/checksum.py
+++ b/bitbake/lib/bb/checksum.py
@@ -50,6 +50,7 @@ class FileChecksumCache(MultiProcessCache):
MultiProcessCache.__init__(self)
def get_checksum(self, f):
+f = os.path.normpath(f)
entry = self.cachedata[0].get(f)
cmtime = self.mtime_cache.cached_mtime(f)
if entry:
@@ -84,15 +85,24 @@ class FileChecksumCache(MultiProcessCache):
return None
return checksum
+#
+# Changing the format of file-checksums is problematic as
both OE and Bitbake have
+# knowledge of them. We need to encode a new piece of data,
the portion of the path
+# we care about from a checksum perspective. This means that
files that change subdirectory
+# are tracked by the task hashes. To do this, we do something
horrible and put a "/./" into
+# the path. The filesystem handles it but it gives us a
marker to know which subsection
+# of the path to cache.
+#
def checksum_dir(pth):
# Handle directories recursively
if pth == "/":
bb.fatal("Refusing to checksum /")
+pth = pth.rstrip("/")
dirchecksums = []
for root, dirs, files in os.walk(pth, topdown=True):
[dirs.remove(d) for d in list(dirs) if d in localdirsexclude]
for name in files:
-fullpth = os.path.join(root, name)
+fullpth = os.path.join(root, name).replace(pth,
os.path.join(pth, "."))
checksum = checksum_file(fullpth)
if checksum:
dirchecksums.append((fullpth, checksum))
diff --git a/bitbake/lib/bb/siggen.py b/bitbake/lib/bb/siggen.py
index 0d88c6ec68..f649f39ced 100644
--- a/bitbake/lib/bb/siggen.py
+++ b/bitbake/lib/bb/siggen.py
@@ -308,13 +308,14 @@ class SignatureGeneratorBasic(SignatureGenerator):
return
def get_taskhash(self, tid, deps, dataCaches):
-
data = self.basehash[tid]
for dep in self.runtaskdeps[tid]:
data = data + self.get_unihash(dep)
for (f, cs) in self.file_checksum_values[tid]:
if cs:
+if "/./" in f:
+data = data + f.split("/./")[1]
data = data + cs
if tid in self.taints:
@@ -372,7 +373,12 @@ class SignatureGeneratorBasic(SignatureGenerator):
if runtime and tid in self.taskhash:
data['runtaskdeps'] = self.runtaskdeps[tid]
-data['file_checksum_values'] = [(os.path.basename(f), cs)
for f,cs in self.file_checksum_values[tid]]
+data['file_checksum_values'] = []
+for f,cs in self.file_checksum_values[tid]:
+if "/./" in f:
+
data['file_checksum_values'].append((f.split("/./")[1], cs, True))
+else:
+
data['file_checksum_values'].append((os.path.basename(f), cs,
[yocto] SRC_URI Directory Change
Is there a recommended strategy to get do_fetch to invalidate on directory
path changes in paths pointed to by file:// URLs in SRC_URI?
Example:
SRC_URI += "file://src;subdir=${S}"
A file at src/foo/bar/baz is recognized just fine. But then a directory
change to something like src/foo/bar2/baz is not recognized and does not
invalidate any tasks in subsequent builds.
Use case is a recipe that has a fair bit of metadata that is not even
remotely amenable to the typical flat layout expected of a set of patches.
..Ch:W..
P.S. I attempted to do this with an event handler that was run when
bb.event.RecipePreFinalise is is fired. It would compare directory trees
and set do_fetch[nostamp] = "1" to invalidate the fetcher task. But I got
really spotty behavior. It seems like event handlers are cached like tasks.
--
*"Perfection must be reached by degrees; she requires the slow hand of
time." - Voltaire*
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#55082): https://lists.yoctoproject.org/g/yocto/message/55082
Mute This Topic: https://lists.yoctoproject.org/mt/86335443/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [OE-core] How to trigger Yocto Linux /etc/profile or shell scripts in /etc/profile.d without shell logging in?
On Sun, Oct 10, 2021 at 9:30 PM JH wrote: > The Yocto uses /etc/profile for root login, but there is no root > physical login in an embedded device so the /etc/profile is never > called, I added a shell script to /etc/profile.d, it was not called > either. Both /etc/profile and scripts in /etc/profile.d can only be > invoked when I physically log into the debug console, that is > impractical. Appreciate your advice, how do you resolve that kind of > problem? > What problem are you attempting to solve by running a script from /etc/profile.d? ..Ch:W.. -- *"Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire* -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#55012): https://lists.yoctoproject.org/g/yocto/message/55012 Mute This Topic: https://lists.yoctoproject.org/mt/86230026/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Getting absolute paths in yocto generated native binary #bitbake #native #toolchain #sdk
Native recipes are meant for the build machine itself to aid your build. If you are packaging something to run on a destination machine, you should be producing non-native recipe images. ..Ch:W.. On Tue, Oct 5, 2021 at 1:59 PM Jean-Pierre Doyon wrote: > I'm attempting to create a USB first boot tarball for our custom iMX6 > board that would contain the imx-usb-loader executable, config files and > u-boot/SPL files. The goal being to deploy that to the production machine > to program the empty boards right after being assembled. > > While I had plenty of hurdles figuring out how to do this (I'm still > pretty newbie with Yocyo), I managed to get everything just the way I > wanted it. But when I get the tarball to the production machine, which runs > the exact same Ubuntu 18.04 LTS Linux as the build machine, the imx_usb > tool won't run. The reason being that it's missing some library. Running > LDD on the executable turns up this: > > └─$> ldd usr/bin/imx_usb > linux-vdso.so.1 => (0x7ffd7031d000) > libusb-1.0.so.0 => /lib/x86_64-linux-gnu/libusb-1.0.so.0 > (0x7f986a47e000) > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f986a0b4000) > libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x7f986a86c000) > libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 > (0x7f9869e97000) > > /home/jpdoyon/newtrax-layersetup-dunfell/build/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2 > => /lib64/ld-linux-x86-64.so.2 (0x7f986a696000) > librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f9869c8f000) > > Why is the ld-linux-x86-64.so.2 using an absolute path while all the other > libraries aren't? > > If I install the library in the location above, then the executable starts > working... So how do I make sure Yocto doesn't do this? > > > > -- *"Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire* -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#54975): https://lists.yoctoproject.org/g/yocto/message/54975 Mute This Topic: https://lists.yoctoproject.org/mt/86104726/21656 Mute #sdk:https://lists.yoctoproject.org/g/yocto/mutehashtag/sdk Mute #toolchain:https://lists.yoctoproject.org/g/yocto/mutehashtag/toolchain Mute #bitbake:https://lists.yoctoproject.org/g/yocto/mutehashtag/bitbake Mute #native:https://lists.yoctoproject.org/g/yocto/mutehashtag/native Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Install packages to an "image" without its dependencies being pulled in. #yocto
Yes.
This is a version of the question - "how do I build an image that *ONLY*
includes the packages I explicitly specify". This involves bypassing a lot
of guards and bitbake tooling, but it can be done.
Your mileage may vary depending on your distro setup. In particular this
assumes you are configured to use the IPK package format. The dnf command
had significant issues a while back, so I switched from RPM to IPK. If you
use RPM, the OPKG_ARGS stuff not going to work for you.
IMAGE_FEATURES = ""
LDCONFIGDEPEND = ""
IMAGE_INSTALL = ""
PACAKGE_INSTALL = ""
OPKG_ARGS += "--no-install-recommends --nodeps --force-depends"
ROOTFS_POSTPROCESS_COMMAND_remove = "systemd_create_users; "
ROOTFS_POSTPROCESS_COMMAND_remove = "rootfs_update_timestamp; "
ROOTFS_POSTPROCESS_COMMAND_remove = "rootfs_reproducible; "
IMAGE_CMD_cpio_prepend() {
IMAGE_BUILDING_DEBUGFS="true"
}
If you want the pre and postinstall scripts to trigger, you need to add an
IMAGE_PREPROCESS_COMMAND function that takes your PACKAGE_INSTALL list and
concatenates the package level control, preinst, and postinst scripts. This
involves unpacking the ipk found in
${WORKDIR}/oe-rootfs-repo/*/${PKG}_*.ipk. You may also want to post-process
the resulting script to remove "set -e" invocations, since those scripts
make assumptions about dependencies that you are (hopefully) safe to ignore.
You may also want another IMAGE_PREPROCESS_COMMAND function that deletes
stuff that can accidentally overwrite your image rootfs files, like
/etc/passwd and /etc/group.
Once you get it all dialed in, you can probably abstract the useful bits to
your own image-layer bbclass so you can trivially reuse it.
..Ch:W..
On Fri, Aug 20, 2021 at 12:36 AM wrote:
> Greetings everyone,
>
> Is there a way to instruct Yocto's image class to install package(s)
> without its dependencies for an image target (i.e ext4)? For instance, we
> are trying to build a system where there is a main system partition and
> another partition that'll host additional lib, etc and during boot up we
> would overlay them together. Hence, the "other" partition does not really
> need all the same system libs, etc that already exists on the system
> partition. This other partition is developed by an external partner so we
> want to have the autonomy to update separately (i.e not mingled things
> together with system partition). I am having trouble finding a way to do
> this because Yocto seem to like to install a package long with all its
> dependencies (i.e glibc, etc).
>
> PS. I apologize if this is not the right place to ask the question.
>
> Thanks,
> Mike
>
>
>
--
*"Perfection must be reached by degrees; she requires the slow hand of
time." - Voltaire*
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54523): https://lists.yoctoproject.org/g/yocto/message/54523
Mute This Topic: https://lists.yoctoproject.org/mt/85016309/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] #yocto Preferred development workflow
We have many recipes appended to IMAGE_INSTALL in our image recipes and it
works just fine.
>From your description, it sounds like you could go either way. I personally
prefer to keep my image recipes as clean as possible, so I push as much as
I can to individual recipes. This helps with debugging later on as your
project (inevitably) gets more complex.
Also... Experience has shown that the following form is a lot more readable:
IMAGE_INSTALL = "recipe_1"
IMAGE_INSTALL += "recipe_2"
IMAGE_INSTALL += "recipe_3"
IMAGE_INSTALL += "recipe_4"
IMAGE_INSTALL += "recipe_5"
Than this:
IMAGE_INSTALL = "\
recipe_1 \
recipe_2 \
recipe_3 \
recipe_4 \
recipe_5"
When your repository grows large, a recursive grep for recipe_2 will make a
lot more sense if "IMAGE_INSTALL += "recipe_2"" is returned instead of
"recipe_2 \". The latter form gives no clue as to how recipe_2 is being
referenced.
..Ch:W..
On Mon, Jul 12, 2021 at 9:36 PM ivin.lim via lists.yoctoproject.org
wrote:
> sorry about that, right now the config files are placed in the files
> directory of the recipe which builds the module.
>
> Sample snippets of the recipe concerning this config file, I removed the
> rest of lines.
> *SRC_URI = " \*
> * file://config.json \*
> *"*
>
> *do_install_append() {*
> * install -m 0644 ${WORKDIR}/config.json ${D}/etc/directory/*
>
>
>
> *}*If I were to have the config files placed on a separate recipe, would
> that mean making multiple of these recipes depending on the number of
> projects?
> I did thought also of adding it in the image recipe but probably this
> wouldn't look well if more things get added.
>
>
> Thanks
>
>
>
>
>
--
*"Perfection must be reached by degrees; she requires the slow hand of
time." - Voltaire*
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54108): https://lists.yoctoproject.org/g/yocto/message/54108
Mute This Topic: https://lists.yoctoproject.org/mt/84171384/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] #yocto Preferred development workflow
You left a few details out about how the configuration files are managed. Ideally you could just make bitbake recipes for the config files themselves. This way you can create an image recipe for each project and use the IMAGE_INSTALL variable to append whatever configs and modules you want on a per-project basis. ..Ch:W.. On Mon, Jul 12, 2021 at 8:40 PM ivin.lim via lists.yoctoproject.org wrote: > Hi everyone, > > I'm curious on a good approach when dealing with multiple projects > > I've just started out yocto and have already created our own meta-layer > which contains our modules. Now these modules would sometimes have config > files and this could vary when each project that we have would use these > recipes. I'm thinking of a way to control this. And I don't think having > one branch per project is a good style. Right now the best way I can think > of is creating seperate "project layers" (ex. meta-project1, meta-project2) > and from there create those .bbappends which would point to the > project-specific conf files. > > But I was wondering if there is a better way of handling it. Thanks. > > Cheers. > > > -- *"Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire* -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#54106): https://lists.yoctoproject.org/g/yocto/message/54106 Mute This Topic: https://lists.yoctoproject.org/mt/84171384/21656 Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] what's the state of things with pushing the bounds on ASSUME_PROVIDED?
On Fri, Jun 25, 2021 at 4:43 AM Richard Purdie < richard.pur...@linuxfoundation.org> wrote: > > In summary, I see a lot of problems for what amounts to not much speed > gain. Particularly when we have a mechanism like sstate available > which allows binary reuse. > Very strong agreement here. My 2c is that Yocto/OE should be going in that direction even further. One of the significant benefits of the OE build method is eliminating, to the greatest extent possible, the (usually) undetectable influence of variations in the host platforms. Any given distro is probably stable enough, but that does not guarantee a consistent result if we attempted to build the same image on all available stable distros. We might get lucky and actually achieve that, but I would not bet my life on it, particularly if we started using even more native tooling. "Stability is a local construct, not a global one." For our own project, we have taken this as far as practical. We eliminated the third party distro host platform (Ubuntu) about five years ago and built our host platform from Yocto/OE sources. Each new version of our host platform is built from the previous one. ..Ch:W.. -- *"Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire* -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53982): https://lists.yoctoproject.org/g/yocto/message/53982 Mute This Topic: https://lists.yoctoproject.org/mt/83758672/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] Hardknott (GCC10) Compiler Issues
All, Please accept my apologies in advance for the detailed submission. I think it is warranted in this case. There is something... "odd" about the GCC 10 compiler that is delivered with Hardknott. I am still chasing it down, so I am not yet ready to declare a root cause or submit a bug, but I am posting what I have now in case anyone has some insights to offer. For all I know it is something unusual that I am doing, but we have a lot of history with our build/dev/release methods, so I would be surprised if that was actually the case. I have also discussed aspects of this on IRC for the last few days, so some of this may be familiar to some of you. Background: We maintain a virtual machine SDK for our developers that is as close as possible to the actual embedded hardware environment that we target. The SDK image is our baseline Linux OS plus lots of the expected dev and debugging tools. The image deployed to our target devices is the baseline Linux OS plus the core application suite. It is also important to note that we only support the x86_64 machine architecture in our target devices and development workstations. We also spin up and spin down the SDK VM for our nightly builds. This guarantees strict consistency and eliminates lots of variables when we are trying to troubleshoot something hairy. We just upgraded from Thud to Hardknott. This means we built our new Hardknott based SDK VM image from our Thud based SDK VM (GCC 8 / glibc 2.28). When we attempted to build our target device image in the new Hardknott based SDK VM, we consistently got a segfault when any build task involves bison issuing a warning of some sort. I traced this down for a very long time and it seemed to have something to do with the libtextstyle library from gettext and the way bison used it. But I now believe that this to be a red herring. Bison seems to be very fragile, but in this case, that may have actually been a good thing. After some experimentation I found that the issue went away when I dropped down to the 3.6.4 recipe of bison found at OE-Core:bc95820cd. But this did not sit right with me. There is no way I should be the only person seeing this issue. Then I tried an experiment... I assumed I was encountering a compiler bootstrap issue with such a big jump (GCC8 -> GCC10), so I rebuilt our hardknott based SDK VM with the 3.3.1 version of buildtools-extended. The build worked flawlessly, but when I booted into the new SDK VM and kicked off the build I got the same result (bison segfault when any build warnings are encountered). This is when I started to mentally put a few more details together with other post-upgrade issues that had been discovered in our lab. We attributed them to garden variety API and behavioral changes expected during a Yocto upgrade, but now I am not so sure. During the thud-to-hardknott upgrade process, we did nightly builds of the new hardknott based target image from our thud based SDK VM. I assumed that since GCC10 was being built as part of the build sysroot bootstrap process, we were getting a clean and consistent result irrespective of the underlying build server OS. One of the issues we were seeing in the lab was a periodic hang during the initramfs phase of the boot process. We run a couple of setup scripts to manage the sysroot before the switch_root, so it is not unusual to see some "growing pains" after an upgrade. The hangs were random with no obvious cause, but systemd is very weird anyway so we attributed it to a new dependency or race condition that we had to address after going from systemd 239 to 247. It is also worth noting that systemd itself was not hung, it responded to the 'ole "three finger salute" and dutifully filled the screen with shutdown messages. It was just that the boot process randomly stopped cold in initramfs before the switch root. We would also occasionally see systemd complaining in the logs, "Starting requested but asserts failed". Historically, when asserts fail, it is a sign of a much larger problem, so I did another experiment... Since we could build our SDK VM successfully with buildtools-extended, why not build the target images? So I did. After a day of testing in the lab, none of the testers have seen the boot hang up in the initramfs stage, whereas before it was happening about 50% of the time. I need a good week of successful test activity before I am willing to declare success, but the results were convincing enough to make it worth this summary post. I did an extensive amount of trial and error testing, including meticulously comparing buildtools-extended with our own versions of the same files. The only intersection point was gcc. The gcc delivered with buildtools-extended works great. When I build hardknott's gcc10 from the gcc in buildtools-extended, we are not able to build our target images with the resulting compiler. When I build our target images from the old thud environment, we get a mysterious hang and systemd asserts
[yocto] Git Fetcher Branch Default
I got a fetcher failure on go-systemd today, which puzzled me. That recipe has not changed in ages, and the SRCPV hash is clearly visible in the repository. After looking at it closer, it seems that github.com/coreos/go-systemd has changed its default branch from master to main about six days ago. This appears to break a fundamental assumption on the part of the fetcher when looking for SRCREV and SRCPV hashes. Looking at lib/bb/fetch2/git.py makes it evident that this is the case. I can trivially fix this with a .bbappend, but it seems to me that the fundamental default branch assumption needs to be updated. Has anyone discussed adding main to the list of default branches to try? If not, I may be able to come up with a patch, but the code does process default branches as a list, so I will need to think a bit on the best way to approach this. Any guidance would be appreciated. ..Ch:W.. -- "Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53474): https://lists.yoctoproject.org/g/yocto/message/53474 Mute This Topic: https://lists.yoctoproject.org/mt/82770938/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Recipe Grep'ing
On Sat, May 8, 2021 at 6:25 PM Robert Joslyn wrote: > There is the oe-stylize.py script that attempts to format recipes > according to the style guide: > https://git.openembedded.org/meta-openembedded/tree/contrib/oe-stylize.py > > Last time I played with it, I was a bit disappointed with some of the > changes it makes, some of which are different than what devtool does. > When I need to introduce new developers to bitbake, I'd love to be able > to hand them oe-stylize or something similar and just tell them to run > it before committing to make sure everything is formatted consistently. > > I've had updating oe-stylize.py on my TODO list for a while, but more > important things always come up. Given what I have seen so far, I am wondering if that is the right place to start. To summarize: There appears to be general agreement that the idea is a good one, but a large patch wall is considered rather objectionable by at least Bruce Ashfield. Khem Raj brought up a good point that a big change like the one I am proposing needs some sort of tooling to make sure we do not regress. And the above reply from Robert Joslyn has me wondering if there is already something in place to do the linting Khem Raj is referring to, or if oe-stylize.py would form the basis for such a tool if we added it to an automated system. So taking a step back, does it make sense to update the guidance on the styleguide (https://www.openembedded.org/wiki/Styleguide) page first? If so, I would be happy to make the updates. I requested an account, but I got an error - "Error sending mail: Unknown error in PHP's mail() function." ..Ch:W.. -- "Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53470): https://lists.yoctoproject.org/g/yocto/message/53470 Mute This Topic: https://lists.yoctoproject.org/mt/82620308/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] Recipe Grep'ing
I was pondering putting some work in to a fairly large patch set aimed at making recipes easier to grep through, and wanted to get some feedback before I put time and effort into it. I have often found that the following pattern cleanly describes the "what" and the "why" when grep'ing through recipes to search for things: FOO += "item1" FOO += "item2" Whereas this pattern gives us the "what", but not the "why": FOO = "item1 \ item2 \ " After discussing this with Richard Purdie on IRC, I also understand that the latter pattern benefits some forms of build output. In addition, for SRC_URI, the "why" is normally fairly obvious from context clues. So, is there any interest in accepting a patch set of that nature for Yocto and OE repositories? If so, what variables and situations should be considered "off limits" to a change like that? ..Ch:W.. -- *"Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire* -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53401): https://lists.yoctoproject.org/g/yocto/message/53401 Mute This Topic: https://lists.yoctoproject.org/mt/82620308/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Hardknott - pseudo excluded from intercept_scripts
The following code is an effective workaround. It must be added after the
core-image is inherited.
python () {
pseudo_ignore_paths = d.getVar('PSEUDO_IGNORE_PATHS')
result = ','.join([x for x in pseudo_ignore_paths.split(',') if
"intercept_scripts" not in x])
d.setVar('PSEUDO_IGNORE_PATHS', result)
}
..Ch:W..
On Tue, May 4, 2021 at 8:53 PM Chuck Wolber via lists.yoctoproject.org
wrote:
>
> I was attempting an image build with Yocto Hardknott, and I ran into a
> chown problem during do_rootfs(). I traced it down to
> ${WORKDIR}/intercept_scripts showing up in the PSEUDO_IGNORE_PATHS
> environment variable.
>
> This commit made the change:
>
> https://git.openembedded.org/openembedded-core/commit/meta/classes/image.bbclass?id=9463be2292b942a1072eea1b9644e55aadb9
>
> I continued down the rabbit hole until I got here:
>
> https://git.openembedded.org/openembedded-core/tree/meta/lib/oe/package_manager/__init__.py#n173
>
> Line 192 specifically is the smoking gun. The files are being copied from
> poky/scripts/postinst-intercepts into the ${WORKDIR}/intercept_scripts
> directory and immediately failing when the copyFile utility attempts to do
> a chown.
>
> Is there any logical explanation for this? Is this a bug or am I doing
> something wrong? Is there a workaround?
>
> ..Ch:W..
>
> --
> *"Perfection must be reached by degrees; she requires the slow hand of
> time." - Voltaire*
>
>
>
>
--
*"Perfection must be reached by degrees; she requires the slow hand of
time." - Voltaire*
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53385): https://lists.yoctoproject.org/g/yocto/message/53385
Mute This Topic: https://lists.yoctoproject.org/mt/82596907/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] Hardknott - pseudo excluded from intercept_scripts
I was attempting an image build with Yocto Hardknott, and I ran into a
chown problem during do_rootfs(). I traced it down to
${WORKDIR}/intercept_scripts showing up in the PSEUDO_IGNORE_PATHS
environment variable.
This commit made the change:
https://git.openembedded.org/openembedded-core/commit/meta/classes/image.bbclass?id=9463be2292b942a1072eea1b9644e55aadb9
I continued down the rabbit hole until I got here:
https://git.openembedded.org/openembedded-core/tree/meta/lib/oe/package_manager/__init__.py#n173
Line 192 specifically is the smoking gun. The files are being copied from
poky/scripts/postinst-intercepts into the ${WORKDIR}/intercept_scripts
directory and immediately failing when the copyFile utility attempts to do
a chown.
Is there any logical explanation for this? Is this a bug or am I doing
something wrong? Is there a workaround?
..Ch:W..
--
*"Perfection must be reached by degrees; she requires the slow hand of
time." - Voltaire*
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53384): https://lists.yoctoproject.org/g/yocto/message/53384
Mute This Topic: https://lists.yoctoproject.org/mt/82596907/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] OPencv 3.1 with Rocko #rocko
Did you try doing a cleansstate on opencv and attempting the build again?
..Ch:W..
On Thu, Apr 1, 2021 at 5:28 AM wrote:
> Observing following error
> while generationg rootfs with Packages of opencv 2.4 and 3.1
>
> RROR: opencv-3.1+gitAUTOINC+92387b1ef8-r0 do_package: Error executing a
> python function in exec_python_func() autogenerated:
>
> The stack trace of python calls that resulted in this exception/failure
> was:
> File: 'exec_python_func() autogenerated', lineno: 2, function:
> 0001:
> *** 0002:populate_packages(d)
> 0003:
> File:
> '/home/tel/imx_yocto_Rocko/sources/poky/meta/classes/package.bbclass',
> lineno: 1109, function: populate_packages
> 1105:d.setVar('FILES_%s' % src_package_name, '/usr/src/debug')
> 1106:
> 1107:# Sanity check PACKAGES for duplicates
> 1108:# Sanity should be moved to sanity.bbclass once we have the
> infrastucture
> *** 1109:package_list = []
> 1110:
> :for pkg in packages.split():
> 1112:if pkg in package_list:
> 1113:msg = "%s is listed in PACKAGES multiple times, this
> leads to packaging errors." % pkg
> Exception: AttributeError: module 'bb.data' has no attribute 'setVar'
>
> ERROR: opencv-3.1+gitAUTOINC+92387b1ef8-r0 do_package: Function failed:
> populate_packages
> ERROR: Logfile of failure stored in:
> /home/tel/imx_yocto_Rocko/build_imx6ull/tmp/work/cortexa7hf-neon-poky-linux-gnueabi/opencv/3.1+gitAUTOINC+92387b1ef8-r0/temp/log.do_package.17885
> ERROR: Task
> (/home/tel/imx_yocto_Rocko/sources/meta-openembedded/meta-oe/recipes-support/opencv/opencv_3.1.bb:do_package)
> failed with exit code
>
> does any one guide me throgh this ?
>
>
>
--
*"Perfection must be reached by degrees; she requires the slow hand of
time." - Voltaire*
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53003): https://lists.yoctoproject.org/g/yocto/message/53003
Mute This Topic: https://lists.yoctoproject.org/mt/81774364/21656
Mute #rocko:https://lists.yoctoproject.org/g/yocto/mutehashtag/rocko
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Including binary application as part of the image output
Your company's application should be built within its _own_ bitbake recipe and then pulled into your image with an RDEPENDS entry in your image build recipe. If you do it that way, you can find the packaged version of your application in the tmp/deploy directory automatically. ..Ch:W.. On Wed, Jan 27, 2021 at 10:32 AM chuck kamas via lists.yoctoproject.org wrote: > Hi all, > > > As part of our image we build our company's application. This > application becomes part of the image and is executed when the image boots. > > My question is how to have the binary image also be available along with > the image's wic file? Is there a line I can add to a recipe to have it > copy that image file to the tmp/deploy directory or other appropriate > directory so that it is available? > > > Thanks! > > Chuck > > > > > > -- *"Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire* -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52120): https://lists.yoctoproject.org/g/yocto/message/52120 Mute This Topic: https://lists.yoctoproject.org/mt/80164330/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Best convention for FILES variable
On Sat, Nov 21, 2020 at 12:21 AM Chuck Wolber wrote:
%< SNIP %<
> And finally, I have adjusted to using the following pattern, and found
> that it has improved maintainability a great deal. It applies to DEPENDS
> and RDEPENDS as well. Yes, it is a bit tedious, but the benefits far
> outweigh the cost (IMHO).
>
> FILES_fooz += " lib/foozlib.so"
> FILES_fooz += " /usr/lib/foozlib-2.so"
> FILES_fooz += " /usr/bin/fooz"
> FILES_fooz += " /bin/fooz"
> FILES_fooz += " /usr/share/fooz"
>
> This pattern is invaluable when you start accumulating a lot of recipes. A
> recursive grep (grep -r) across a directory tree, will immediately tell you
> that (for example), /bin/fooz is file in the fooz package and it is
> referenced in the fooz_1.3.2.bb recipe.
>
I forgot one other benefit. When a change is made to a recipe that uses
that pattern, the (Git) commit diff is a lot clearer and easier to
understand.
Think of it this way... Use your pattern, but imagine there are a lot more
entries in your list. A change to the middle of that list is going to
result in a diff that is hard to determine if it is a FILE_fooz entry or a
DEPENDS_${PN} entry. Prefixing with the directive keeps your Git history a
lot clearer.
..Ch:W..
--
*"Perfection must be reached by degrees; she requires the slow hand of
time." - Voltaire*
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#51504): https://lists.yoctoproject.org/g/yocto/message/51504
Mute This Topic: https://lists.yoctoproject.org/mt/78404917/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Best convention for FILES variable
On Fri, Nov 20, 2020 at 6:49 PM wrote:
> Hello,
> I am relatively new to yocto, and I am working on several recipes at the
> moment and I'm wondering about using wildcards in my FILES_{PN} list. None
> of the packages have more than 5 or 6 files to package. They could easily
> be covered with two wildcard entries, but I wonder if there is benefit to
> listing each file explicitly. Thanks for the help. Example below:
>
> FILES_fooz = "\
> */fooz* \
> */*/fooz* \
> "
>
> vs
>
> FILES_fooz = "\
>/lib/foozlib.so \
>/usr/lib/foozlib-2.so \
>/usr/bin/fooz \
>/bin/fooz \
>/usr/share/fooz \
> "
>
>
Both will work, although you do run the risk of accidentally globbing files
that you do not mean to include, but perhaps you know your recipes well
enough that that is not a factor.
Personally, I find that being explicit makes a lot more sense for a few
reasons:
- Stuff changes, and I _want_ a build error or warning to let me when it
changes and someone forgot to update the recipe.
- The grep command is your friend. If you glob, you lose a lot of
fidelity there.
- If you want to refactor a recipe into separate packages later, you
probably need to do a lot of head scratching to pin down all of the files
generated in the build.
And finally, I have adjusted to using the following pattern, and found that
it has improved maintainability a great deal. It applies to DEPENDS and
RDEPENDS as well. Yes, it is a bit tedious, but the benefits far outweigh
the cost (IMHO).
FILES_fooz += " lib/foozlib.so"
FILES_fooz += " /usr/lib/foozlib-2.so"
FILES_fooz += " /usr/bin/fooz"
FILES_fooz += " /bin/fooz"
FILES_fooz += " /usr/share/fooz"
This pattern is invaluable when you start accumulating a lot of recipes. A
recursive grep (grep -r) across a directory tree, will immediately tell you
that (for example), /bin/fooz is file in the fooz package and it is
referenced in the fooz_1.3.2.bb recipe.
..Ch:W..
--
*"Perfection must be reached by degrees; she requires the slow hand of
time." - Voltaire*
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#51503): https://lists.yoctoproject.org/g/yocto/message/51503
Mute This Topic: https://lists.yoctoproject.org/mt/78404917/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] do_unpack() ISO Image
Hi all,
I have a need to unpack an ISO image during do_unpack. This does not appear
to be one of the extensions that is handled by default, so I am working out
a way to use xorriso to do this for me.
I can get this to work in the following way, but it involves calling an
executable running on the build host, which only works by luck since the
host executable is the same architecture as what I am currently building. I
would like to do this in a portable way that does not break when I try to
build for a different architecture.
DEPENDS += "xorriso"
do_unpack_append() {
bb.build.exec_func('unpack_iso', d)
}
unpack_iso() {
/usr/bin/xorriso -osirrox on -indev ${WORKDIR}/${PN}_${PV}.iso -extract
/ ${S}
}
>From looking at base.bbclass, it _seems_ as if my solution involves
something like this:
d.appendVarFlag('do_unpack', 'depends', ' xorriso:do_populate_sysroot')
But it is unclear exactly where that would go within my recipe. Any
thoughts?
Thank you,
..Ch:W..
--
*"Perfection must be reached by degrees; she requires the slow hand of
time." - Voltaire*
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50718): https://lists.yoctoproject.org/g/yocto/message/50718
Mute This Topic: https://lists.yoctoproject.org/mt/76924178/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Patching file contained in downloaded recipe
On Mon, Sep 14, 2020 at 3:05 PM Greg Wilson-Lindberg
wrote:
> Hi Chuck,
>
>
>
> I am patching a recipe that is included with the Yocto system that I
> download. The .system file that I need to modify is in one of the file
> directories that are part of the recipe.
>
>
>
> I have a .bbappend recipe that is being picked up, but because the file
> that I want to patch is part of the recipe and not part of what a recipe
> would download if it were building something from source, the patch system
> is not finding it.
>
In that case, your best bet is to probably write a do_*_append() function
into the bbappend recipe so you can jump in after one of the build steps
and apply your patch during the appropriate stage. Refer to section 28.1 of
the Mega Manual for all of the build tasks, and pick one that seems
sensible. For example, you can write a do_install_append() function, and
then prepend ${B} to the path that the service file typically shows up at
to access it. From there, it is a simple matter of using typical commands
to apply whatever patch you want.
I have no doubt that other, more experienced people on the Yocto project,
may suggest a better target than do_install, so listen to them if any
should jump in and offer sensible correction to what I am saying.
Part of my question was, could I use the PATCHDIR option to specify the
> /lib/systemd/system/file.service file to get the patch to run against the
> ‘copied’ version of the file?
>
Given the example above, you would simply use
${B}/lib/systemd/system/file.service and use garden variety command line
tools to apply the patch.
> Sorry for the weird “…” blocks, I’m stuck with Outlook for
> email and I can’t figure out how to get it to indent the email I’m replying
> to and let me comment in line without indenting my replies also.
>
No worries. I used to use mutt and pine, which were really good at inline
posting. Alas, I have moved on to gmail, which is not so good, and comes
into conflict in places such as this. We make-do of course...
..Ch:W..
--
*"Perfection must be reached by degrees; she requires the slow hand of
time." - Voltaire*
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50676): https://lists.yoctoproject.org/g/yocto/message/50676
Mute This Topic: https://lists.yoctoproject.org/mt/76848145/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Patching file contained in downloaded recipe
On Mon, Sep 14, 2020 at 10:50 AM Greg Wilson-Lindberg wrote: > I have a recipe that has a .service file in one of its files directories > that I need to patch. > > > > I haven’t been able to figure out how to specify the directory of the file > that needs to be patched. I can’t seem to get the patch to apply to the > files directory, do I need to specify the /lib/systemd/system directory > into the PATCHDIR option or is there another way that would work better? > Are you patching an existing upstream recipe? Or your own recipe? In the former case, you would use a .bbappend recipe. In either case, it all depends on how the service file is generated. If it is part of the source code, then you just create a patch against the source tree and reference that patch in a recipe as a SRC_URI_append. If you generate it as part of a build, then you would either patch the build product (less desirable), or patch the code that generates the service file (more desirable). ..Ch:W.. -- *"Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire* -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#50673): https://lists.yoctoproject.org/g/yocto/message/50673 Mute This Topic: https://lists.yoctoproject.org/mt/76848145/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Yocto Project Status WW04'20
On Sun, Feb 2, 2020 at 6:09 AM Alexander Kanavin wrote: > Why separate them? I’d rather have newbies and experts in the same room.. > Enthusiastic second to this. If you separate things too much, newbies get no sense of the depth of the project, and experienced people get less of a sense of the "newcomer pain points". Granted, this breaks down when traffic elevates to to LKML levels, but we are not even close to that (yet). ..Ch:W.. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#48242): https://lists.yoctoproject.org/g/yocto/message/48242 Mute This Topic: https://lists.yoctoproject.org/mt/70220917/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] patchutils bitbake recipe
> > Write a recipe and submit :) I don't think there was ever a "conscious > decision" to not support a specific package for non-technical reasons. > And this one doesn't also look like it has any noteworthy implications - > its autotoolized and GPLv2. So a good one to get involved for sure. > Thanks! It sounds like I am not stepping into an historical tarpit then. There are so many references to patchutils in the Yocto ecosystem that I figured there just had to be some reason for the non-existence of a recipe. Indeed such a recipe looks fairly simple. I will check the appropriate layer README for patch submission details. The only thing that *could* theoretically happen, is that if no usecase > other than a very specific one of yours can be seen, that you are asked > to keep it in a layer of your own instead of being accepted into > meta-openembedded (because thats where it would have to go). > Well, while I have your mind on that topic... I spent a great deal of time building a self hosting/building yocto environment. I started with an Ubuntu install, built an image that met all of our internal development needs, and then discarded the Ubuntu install. This development image inherits from the image that builds the embedded OS we deliver as a product. Our developers now work from our Yocto built environment to do their development. Updates are built within that image and all developers move on to the next one as needed. This approach ensures that application development done for our embedded OS is guaranteed to be consistent. Over the last few years it has resulted in a lot of tangible benefits. There are many more details, of course (Virtual machines are used, etc), but that should set the stage. As we embark on our next version, it occurs to me that Richard Purdie's excellent combo-layer tool is a better way of managing all of the upstream repos. As I was experimenting with it, I found that patchutils is nowhere to be found in the yocto ecosystem. So... is "building a self-hosting" environment a decent use case? I think as it becomes easier to do this, it will become de rigeur to work from an environment like that. And sorry in advance if I opened any cans of worms :) Thanks, ..Ch:W.. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#47904): https://lists.yoctoproject.org/g/yocto/message/47904 Mute This Topic: https://lists.yoctoproject.org/mt/69536251/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
