**** BEGIN LOGGING AT Fri Mar 26 02:59:56 2021 Mar 26 05:31:48 rr123_: https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-metadata.html#inline-python-variable-expansion Mar 26 06:54:46 Hi all, Mar 26 06:54:46 i have small concern with BSP layer of Yocto and android, i want to understand what is exact diff between them,where they will vary from each other because it seems like android is built on top of linux kernel ???? Mar 26 07:04:05 Can someone please help ?? Mar 26 07:10:37 read about GNU/Linux and Android SW architecture, that will show you the diff. sounds like you want us to solve your school homework Mar 26 07:30:08 good morning Mar 26 07:42:56 mcfrisk no i dont want you to solve my school homework i was just asking for the way to do it myself Mar 26 07:43:27 Thanks for suggestion Mar 26 08:11:47 yo dudX Mar 26 09:17:46 Hi ndec: https://bugzilla.yoctoproject.org/show_bug.cgi?id=14330 - The bug we were talking about yesterday. Don't hesitate to add your ideas! Mar 26 09:18:15 thx... Mar 26 09:20:01 Hi rr123_ : I sent a patch corresponding to your idea to improve the "Quick Build" doc: https://lists.yoctoproject.org/g/docs/message/964 - Reviewers are welcome! Mar 26 10:55:19 Is there a way to disable "sanity" checks for oe-selftest? I'd like to use it to just check existence of files in ${D} and every invocation calls for bitbake -e and other stuff making it super slow... Mar 26 11:29:44 I am having a large code base with yocto build system. As part of anaylsing a bug, I need to find out details about one particular function. Mar 26 11:29:45 I need to find out which library implements this function. Out of so many libraries generated using bitbake, how to know which one implements this function. ? When I grep for name of this function, it is been defined  in several code repos by different recipes. Mar 26 11:29:45 How to identify the exact library. ? Mar 26 11:40:08 I have an application creating a plethora of build artifacts. Mar 26 11:40:09 I end up with an executable foo/app and auxiliary files foo/aux1 foo/aux2 etc. Mar 26 11:40:09 To run foo, the whole dir is needed. What's best practice to install such an app? Mar 26 11:40:09 Currently, I install the dir as /usr/libexec/foo/ and create a /usr/bin/foo script with cd and exec. Mar 26 11:40:09 Does this comply? Mar 26 11:40:30 JosephAntony: bitbake -e should give you the complete evaluation including paths. Mar 26 11:42:08 jmiehe: if it works, i wouldn't object. just make sure you're using a correct way of installing the directory, not just cp -r Mar 26 11:45:21 LetoThe2nd: It just feels wrong, as the aux files are not executables. Is /usr/share better suited for stuff like this maybe? Maybe even /opt? Mar 26 11:45:21 I do install correctly, but what'd be wrong about cp -r besides permissions? Mar 26 11:49:15 jmiehe: permissions and ids, is that not enough? for the actual destination selection, i wouldn't be too strict - assuming that you are the integrator and can completely design the filesystem, do whatever feels right and works. the FHS can give some pointers. Mar 26 11:49:59 i personally would probably go for /usr/share, but hey, thats certainly not authorative Mar 26 11:56:55 wait, ids as in uid and gid or as in inode stuff as well? Mar 26 11:57:02 LetoThe2nd: ↑ Mar 26 11:57:27 uid/gid AFAIK Mar 26 11:57:46 there is a good example on stackoverflow, just google for it. Mar 26 12:56:03 what's the difference between `bitbake -s` vs `bitbake-layers show-recipes`, the latter output more recipes somehow Mar 26 13:12:53 rr123: bitbake -s is a much older command Mar 26 13:14:18 so I should use bitbake-layers show-recipes then, refresh old memories about yocto and info are kind mixed Mar 26 13:17:10 it's definitely getting better, if there is a simple page about what is preferred commands, what is 'obsolete/phasing-out' that would be nice Mar 26 13:18:09 rr123: I don't think any decision has been made about that, I'm just saying bitbake-layers is a more recent/modern command so it is more capable than bitbake -s which is older and doesn't really understand layers Mar 26 13:57:45 Hi, anyone an idea what is wrong if I get a "package has no installation candidate"?.(and how to get rid of it) Mar 26 13:57:46 The package is something I made myself, it has no real content, only a do_install() that does a pip3 install of a .whl file that comes from pypi Mar 26 14:21:14 hi all -- how do you guys manage python and (machine) dependencies? (i.e. cross-build dynamic librairies and such) Mar 26 14:24:13 do you have packages for all python librairies, or do you embedded an environment libre virtualenv/pipenv with a compiler etc.? Mar 26 14:24:42 Guest88867: standard approach is recipe per library. see meta-python. Mar 26 14:26:20 LetoThe2nd: just found it, thank you. Mar 26 14:28:24 where does "getVar" come from? is it a function defined within python itself, or some functionality added by bitbake? Mar 26 14:28:56 i looked in the bitbake manual and, while it provides several examples, it doesn't specify how it works Mar 26 14:29:04 at least not that i found Mar 26 14:38:24 yates: It's provided by bitbake Mar 26 14:39:04 JPEW: where is it defined? e.g. where are the arguments defined? Mar 26 14:39:54 data_smart.py in bitbake Mar 26 14:40:13 k, thanks JPEW Mar 26 14:41:04 yates: Be warned: there be dragons (and a cookie monster) in there :) Mar 26 14:41:29 "cookie monster love cookies!" Mar 26 14:45:45 make sure you have enough to pay the toll Mar 26 15:29:30 is d == bb.data? Mar 26 15:36:23 yates: d is a DataSmart object, not a python module Mar 26 15:48:27 kergoth: well bb.data has a GetVar() function: http://paste.ubuntu.com/p/8m7fV2tVGv/ Mar 26 15:48:34 getVar Mar 26 15:55:07 is bb.data a class? if so, does it have its own getVar() method, or is it inherited from DataSmart class? Mar 26 16:05:09 is the bb module part of poky? Mar 26 16:06:50 i mean is the source in poky? i don't think so - "find . -name bb.py" came up blank Mar 26 16:07:12 bb is bitbake and is part of poky Mar 26 16:07:25 the source is there? Mar 26 16:08:52 poky is bitbake+oe-core+meta-yocto/meta-poky Mar 26 16:08:56 bitbake/lib/bb/__init__.py Mar 26 16:09:12 along with the rest of the modules in the python package.. Mar 26 16:12:19 k, thanks kergoth Mar 26 17:36:15 kergoth: somehow that funcs flag change is breaking an sstate selftest :/ Mar 26 17:36:45 kergoth: I started to look into it but found the stdout/stderr handling for the test parallelism is broken so got totally sidetracked :/ Mar 26 17:37:02 kergoth: oe-selftest -r sstatetests.SStateTests.test_sstate_noop_samesigs if you want to take a look Mar 26 17:40:47 how can I hook a custom scp command after do_image_squashfs from my local.conf? Mar 26 17:51:03 vdl: http://paste.ubuntu.com/p/6ysYBdC9v4/ Mar 26 17:51:06 ..roughly.. Mar 26 17:53:39 you can't do "scp" in python, but there is probably some library you can import to do it Mar 26 17:54:32 https://stackoverflow.com/questions/250283/how-to-scp-in-python Mar 26 17:56:11 RP: that's... odd. i'll take a look Mar 26 17:56:12 If you drop the "python" prefix on the function, it will be a shell function which might be easier in this case Mar 26 17:57:13 JPEW: +1 Mar 26 17:58:11 although i admit a special abhorrence of bash scripts... Mar 26 18:15:37 but question is, can I do that from the local.conf, or do I have to bbappend the built image recipe? Mar 26 19:13:30 hello Mar 26 19:13:46 anyone use yocto over voidlinux Mar 26 19:14:13 hechos: what's your question? Mar 26 19:14:15 already compile but im not sure about dependecies Mar 26 19:15:07 let connect to other server and give more idea what logs say. Mar 26 19:27:16 vdl: https://termbin.com/cj1t Mar 26 19:30:07 guys need some help Mar 26 19:30:46 apparently got no errors but cannot run my build Mar 26 19:31:06 here is the logs: https://termbin.com/cj1t Mar 26 19:33:34 https://termbin.com/ryu0 Mar 26 19:35:16 hechos: I recommend you to build in a container satisfying all the host requirement Mar 26 19:35:36 vdl: yes is was im thinking. Mar 26 19:35:43 vdl never work with docker. Mar 26 19:36:00 vdl: what is the best strategy to start? Mar 26 19:36:19 debian docker or ubuntu docker? Mar 26 19:36:46 hechos: I would use a docker image already satisfying yocto dependencies Mar 26 19:37:03 vdl: okey where can download it? Mar 26 19:38:14 seem better to isolate enviroment to build right? Mar 26 19:41:42 hechos: I suggest you to use kas, that's a wrapper for bitbake-based project, which provides a kas-container wrapper script to run the build in docker: https://github.com/siemens/kas Mar 26 19:45:01 but you can directly use the said docker image if you prefer: https://github.com/orgs/siemens/packages/container/kas%2Fkas/1292473 Mar 26 19:48:18 Hi everyone, first time using yocto, I went through the quickstart and I see that my config in build/conf is git-ignored, if we want to have our own "project" so have our own git where we keep track of the changes, what's the right way? create our own layer? or our own distro? Mar 26 19:49:19 alex88: it really depends on what you're trying to achieve. I'd start simple with a single repository (layer) containing all you need. Mar 26 19:50:09 you'll figure out later if you need a custom distro, if it needs to be in a separate layer inside the same repo or in its own repo, etc. Just start simple. Mar 26 19:52:04 vdl, thanks! should we have our own repo with just a layer and when we want to build the image we clone yocto and add our layer, or should we clone yocto, add our own layer folder and push that to our repo and in case we want to udpate we rebase the original yocto repo? Mar 26 19:54:10 Hey guys! I'm getting started with using Yocto at work, and I've got our existing stuff in a self hosted pip and rpm server. The RPMs use pip in the pre install scripts to handle dependencies.  I need to add our internal pip server to the pip config, add the internal rpm server to the rpm config, and then just install the existing packages. Is Mar 26 19:54:11 there a way to just have Yocto add an existing RPM to the build instead of having it create a new one from the source files? Mar 26 19:54:46 hechos: There is also pyrex: https://github.com/garmin/pyrex Mar 26 19:55:00 alex88: start with a repo being the layer itself, containing conf/layer.conf, recipes-*, etc. I suggest you to start right away with kas, that's a tool (think of it as Make) which reads a .yml file (think of it as a Makefile) and handles the download of the layers (such as poky), and bootstrap the build/conf/*.conf files. Mar 26 19:55:27 JPEW: im reading how docker works. Mar 26 19:55:37 act like VM Mar 26 19:55:41 cool. Mar 26 19:55:58 * armpit man, JPEW is pushing kitchen ware Mar 26 19:56:06 * armpit pyrex Mar 26 19:56:10 vdl, thanks a lot I'll look into kas! Mar 26 19:56:49 yeah thanks vdl Mar 26 19:56:58 sorry got logoff to setup docker. Mar 26 19:57:04 alex88: as JPEW pointed out, there are other tools, anything that suits you is fine. It might just help you wrap your head around the basic first steps. Mar 26 19:57:39 so with my later + kas I'll be able to get all I need create a minimal image (which is all I want).. the less files I have around the better it is :D Mar 26 19:57:44 thanks JPEW I'll look into that too! Mar 26 19:58:39 kas is more complete over pyrex right? Mar 26 20:00:10 hechos: Sort of. kas does a lot more than pyrex; pyrex just focuses on wrapping the build in a transparent container Mar 26 20:00:23 Disclaimer: I wrote Pyrex and don't use kas ;) Mar 26 20:01:06 hechos: If pyrex it working properly, you won't even really know it's there; you still run the command `bitbake ...` and it transparently makes that run in the container :) Mar 26 20:01:13 kas could use pyrex in fact :/ Mar 26 20:01:21 just to make sure, my repo should start with the contents of `bitbake-layers create-layer meta-mylayer` right? Mar 26 20:01:45 alex88: that's a good start yes Mar 26 20:01:54 ok! Mar 26 20:03:16 JPEW: okey. Mar 26 20:03:35 vdl: Ya, I've thought about that before Mar 26 20:03:45 alex88: but what matters the most really is conf/layer.conf, everything else are examples. Mar 26 20:03:49 so you recommend use pyrex to get more familiar with yocto build process Mar 26 20:04:21 JPEW: pyrex could use kas as well, works both ways Mar 26 20:05:18 hechos: I think it would be a good idea for you to get familiar with the Yocto build process, period. I wouldn't worry about kas or pyrex or containers or build environments too much until you have a handle on the way the build process works Mar 26 20:05:50 vdl, which is where I'll be able to do config changes like when I've changed build/conf/local.conf in the quickstart? Mar 26 20:06:02 vdl: I haven't looked at their containers too much... Pyrex has some... unusually... things it has to do to run "transparently" Mar 26 20:06:12 JPEW: problem is, he's using Voidlinux... And any non-officially supported distribution for the host is gonna be a PITA Mar 26 20:06:25 vdl: Ah, I missed that Mar 26 20:06:40 Can I just drop an existing RPM into the DEPLOY_DIR_RPM directory to have yocto install it? Mar 26 20:06:55 pyrex would be a good start without impacting your workflow if you can't rely on host support Mar 26 20:08:08 armpit: My second job is selling Pampered Chef to my friends and family.... want some ;) Mar 26 20:08:14 alex88: no. conf/layer.conf describes the layer, its dependencies, etc. Mar 26 20:08:52 hechos: Are you using poky? Mar 26 20:08:58 vdl, and where should I configure the machine type, package_classes etc? Mar 26 20:09:15 alex88: local.conf, to start simple. Mar 26 20:09:44 oh in the root of the repo? let me just create a layer and see what's in it (I was still building the minimal default image for testing) Mar 26 20:13:41 alex88: basically yocto is just an umbrella project for many layers. The job of the user is to somehow fetch the required layers on their machine, specify them in build/conf/bblayers.conf, specify at least which machine and distro to build in build/conf/local.conf, then run bitbake . And there are tools out there to simplify/automate some or all of these preliminary steps. Mar 26 20:15:26 (in order to have the "bitbake" command, a bootstrap script must be sourced.) Mar 26 20:25:07 Quick question, how would I go about pulling an RPM from a package server and installing it via the bitbake? I assume I would build a recipe to do so, is this possible? Assume that the correct arch is defined in the RPM. The GOAL is to package python code in a multi-arch RPM so I can add my directory/file setup to the included python files and use Mar 26 20:25:07 that RPM packaging for multiple purposes (i.e. yocto, x86, x86_64, etc...). Any ideas? Mar 26 20:28:11 vdl, right, but if we (as a company) have a repo with a single layer, then whoever checks out the repo will have to do the required build/conf/* changes to build the image right? so the repo won't have all the required information to build a final image Mar 26 20:28:24 I know the right way to do this would be to build a recipe and have bitbake build the RPMs, but it would be a shame to have to do the packaging "twice" to build yocto RPMs with all the files and directories I require using recipes and then do it again with RPM building for other arch purposes when I'm doing the work once already. Mar 26 20:29:20 alex88: correct. That's why the default yocto way is to specify the requirements in the README file (read a few to see what I mean). Mar 26 20:32:04 alex88: if you want your users (including yourself) to simply clone and execute a single command in order to build a final image, you need to either write your own script which clones, creates bblayers.conf and local.conf, sources the init script and triggers the build; or you use a tool like kas which allows you to specify all this in a .yml file and run your build with "kas build ". Mar 26 20:32:25 oh ok, I'll search for some yocto projects.. Mar 26 20:32:45 vdl, will probably go that route, so I can (hopefully) have my layer + the yml file to build everything Mar 26 20:33:13 I can show you an example if you'd like Mar 26 20:33:59 I'd love to, I just don't want to ask too much and use your time :) Mar 26 20:34:20 my pleasure, it's friday. Mar 26 20:34:27 :) Mar 26 20:35:21 alex88: in order to build the "core-image-minimal" image for the poky distribution for the beaglebone board, you can use this .yml file: http://ix.io/2Uc4 Mar 26 20:36:40 oh ok, I see it defines the machine, target, distro etc... so I"ll just have to have that plus my custom layer with the required customizations... (and somehow add the sstate mirrors etc) Mar 26 20:36:44 alex88: then either you install kas on your machine, or you use the docker container they provide which satisfies the basic yocto dependencies and includes the kas tool: https://raw.githubusercontent.com/siemens/kas/master/kas-container Mar 26 20:37:18 yeah I was reading about it here https://kas.readthedocs.io/en/latest/userguide.html#usage Mar 26 20:37:46 alex88: with these two files, simply running "./kas-container build file.yml" will download everything and build an SD card image in a container, bootable on a beaglebone. Mar 26 20:38:28 looking at https://kas.readthedocs.io/en/latest/userguide.html#use-cases it seems that the "meta-project" will be our repo Mar 26 20:39:52 and I can have also multiple yml files that reference a base one so we can build multiple images (in our case probably beaglebone black + rpi) Mar 26 20:40:53 so a regular user will just create a folder, clone the repo in it and run kas build Mar 26 20:40:56 sounds simple enough :) Mar 26 20:41:21 alex88: yes, if the repo containing the .yml file is a layer itself, you can specify it in the list of repos with an entry not containing "url" nor "refspec". Mar 26 20:41:37 right, like this one ou can specify it in the list of repos with an entry not containing "url" nor "refspec". Mar 26 20:41:40 wops Mar 26 20:41:46 like this one https://kas.readthedocs.io/en/latest/userguide.html#project-configuration Mar 26 20:43:33 alex88: yes, the layer needs a name, which is "meta-custom" in this example (it can be anything, it just described $PWD) Mar 26 20:43:57 I'm wondering if we should instead have a single repo where everything except the meta-custom folder is gitignored so in the future we can maybe add more layers into one repo and the user doesn't have to create a parent folder to do the build Mar 26 20:45:09 alex88: that's what I'm doing. I let kas download the various meta-* layers in the source repository, and I specify them in .gitignore Mar 26 20:45:36 I used to build in the parent folder but going back and forth was boring for development. Mar 26 20:45:46 ok so that's not a bad practice Mar 26 20:45:49 good to know :) Mar 26 20:46:24 yeah exactly, it's a single project but it'll be nice to be able to have multiple layers to organize the code.. those can also be moved outside later if needed Mar 26 20:48:02 alex88: as long as you don't need to share only a subset of the layers outside the company you can also have many layers inside your repository and specify them in the .yml file with layers: ... Mar 26 20:48:59 and that's the yml file inside a single layer, or you mean creating a yml file in the root? Mar 26 20:50:28 or layers:... references all the layers in the parent folder? Mar 26 20:50:37 alex88: I meant that your repository can be a layer itself, containing conf/layer.conf and recipes-* folders, or it can contain many layers, meta-foo, meta-bar, etc. Mar 26 20:51:00 my idea was to have it contain many layers Mar 26 20:51:17 so when you clone the repo you already have the parent folder you need to build the project Mar 26 20:51:42 alex88: in the former case, you'd specify meta-mylayer: in the .yml file. If the latter case you'd specify meta-mylayer: layers: meta-foo: meta-bar: ... Mar 26 20:52:30 oh because in the latter meta-mlayer is the name of the repo containing the sub-layers? Mar 26 20:52:49 e.g. repo called meta-mlayer which contains meta-foo, meta-bar Mar 26 20:53:48 alex88: the best practices is to have one yocto layer per machine/distro/features, but for example I still use a single layer with all my machines variants, a few distros and custom package recipes. Mar 26 20:54:06 because I just don't have the need to split or share portions of them at the moment. Mar 26 20:54:30 ok, let me just try what i can come up with, so I can better understand what I'm doing :) thanks a lot vdl! it sounds like this is going to be a lot of fun! let's see what time I go to bed tonight :) Mar 26 20:56:25 alex88: I strongly suggest to start simple: one layer (the repository itself) containing everything and a single .yml file. Mar 26 20:56:25 JPEW: yeah poky why? Mar 26 20:57:11 vdl, I'm doing that, just as a subfolder, so I can have the main folder ready for my colleagues, if that doesn't work out I can easily move the layer in the root Mar 26 20:57:13 alex88: (and the kas-container wrapper script from the kas repo) Mar 26 20:57:36 vdl, yup! Mar 26 21:17:27 got the first image building! now I just need to add the sstate cache to save some work.. also I had to use `meta-myrepo: { path: meta-myrepo }` in the kas config since the layer is in the subfolder of the repo Mar 26 21:21:47 RP: ah, the noop_samesigs test wants to confirm sigs dont change due to buildhistory addition, but buildhistory does add to the sdk postprocess operations, which previously didn't change checksums. might need vardepsexclude? Mar 26 21:27:44 is there a page where I can see what the default minimal image includes? I see it building sqlite/python and other tools I don't really need (unless they're needed in a very minimal OS) Mar 26 21:31:36 oh might be because of debug-tweaks Mar 26 21:38:38 nope :) Mar 26 21:41:26 alex88: might be some host tools as well Mar 26 21:42:51 hopefully the final image won't be too big, it didn't seem to include so many packages looking at https://wiki.yoctoproject.org/wiki/Minimal_Image#Packages_list Mar 26 21:48:08 like "docbook-xls-native" or "gnome-desktop-testing".. :) why... Mar 26 21:50:23 alex88: yocto pulls in a lot of stuffs, especially for the host Mar 26 21:51:18 so this is only required for the host? maybe it builds everything that's available and then includes only what's needed? Mar 26 21:51:36 with a bit of work you can have a pretty small image, but if you're looking for a build system with the smallest footprint by default, you're not looking in the right direction in my personal opinion ;-) Mar 26 21:52:23 because looking at the minimal image packages, it really looks it only contains what's needed to boot and login :/ Mar 26 21:52:54 there you go Mar 26 21:53:51 I'll look into the .dot files to see why it's building 3+k packages :) Mar 26 22:22:25 https://gist.githubusercontent.com/alex88/eb453bc2b191a4c390168f90d311e5b1/raw/0e50ee991037a98eccb0a42972bc37dd0dfc264f/gistfile1.txt doesn't look so minimal Mar 26 22:29:49 ok got it down from 3+k packages to 1.8k :) Mar 26 22:32:13 oh wait, there is also poky-tiny as a distro Mar 26 22:46:12 kergoth: that sounds like it might make sense Mar 26 22:54:37 is there a default target image size? I'm getting this error https://gist.githubusercontent.com/alex88/ff704d3735d807357713199264c1d97a/raw/833689084422f9117003b88e35661f0111dde9e6/gistfile1.txt Mar 26 22:59:12 or, where does it define the partitions to be used? Mar 26 22:59:57 kergoth: did you have a fix? Mar 26 23:07:19 if I change IMAGE_OVERHEAD_FACTOR shouldn't the calculated IMAGE_ROOTFS_SIZE change? Mar 26 23:10:21 well, using IMAGE_OVERHEAD_FACTOR = "2" fixed the problem, however it doesn't sound like a good solution, it means openembedded isn't able to calculate the final image size? Mar 26 23:43:23 Hello, I'm currently running into a bitbake worker issue in which bitbake fails due to a BrokenPipe exception: https://paste.ubuntu.com/p/x2whyfrF6y/. This issue just appeared on my team's release build infrastructure, and has not occurred until today. This is happening on a new Google Cloud Platform machine, and it occurs during the *second* bitbake command run during the build. The first command Mar 26 23:43:24 is to clean a bunch of recipes (even though they have not yet been built), and the second command is to build an image recipe. Any ideas on how to resolve this issue? Mar 27 00:15:42 the issue I described above has disappeared, just as mysteriously as it had appeared. **** ENDING LOGGING AT Sat Mar 27 02:59:58 2021