**** BEGIN LOGGING AT Wed Mar 17 02:59:56 2021 Mar 17 07:53:25 good morning Mar 17 07:53:50 Hi! I have a kernel and bootloader combo from some old NXP crapper that boots, for reasons not related to this question I've ripped out u-boot, arm-trusted-firmware, and imx-firmware from bitbake and build it on the side, flash it to the mmc of my imx8mn-ddr4-evk board and try to boot a fit image with the same kernel and dtb as before. Thing is, I'm getting a kernel panic when booting and I'm not really Mar 17 07:53:56 sure what went wrong. I'd appreciate very much if someone could have a look at it. https://pastebin.com/mQ6m1fWq Mar 17 07:55:00 I'm not expecting someone to solve my problem but I'm pretty much stuck on this for several days so just asking some relevant questions might lead me on the right path Mar 17 08:28:43 Hello community, I have some trouble with a self written external kernel module, very close to the hello_mod example. My module also provides a public header file to be provided to all code using the module. Can someone help me with the correct way to install this header? Do I modify my kernel module makefile or do I deploy the header with Mar 17 08:28:44 do_install_append from the recipe? Thanks! Mar 17 08:33:09 yo dudX Mar 17 08:33:48 o/ Mar 17 08:34:11 hello :-) Mar 17 08:34:21 qschulz: \o Mar 17 08:35:36 khem: ping Mar 17 08:36:57 MartinH97: if you need to share a header during compilation time, you should install the file in a directory listed in SYSROOT_DIRS (${include} is :) ) if you need it at runtime, you need to install in a directory that is included in a package that you ask Yocto to install in the image (IMAGE_INSTALL usually) Mar 17 08:37:31 to define which directory is installed in which package, have a look at FILES_${PN}* variables Mar 17 08:41:50 qschulz thanks! When I add the following to modules_install in the module Makefile I get an error /usr/share/include no access rights: "install -m 644 -D header.h $(DESTDIR)$(includedir)/header.h" Mar 17 08:42:40 When I try to do this via do_install_append() I get the error: run.do_install.4165502: 111: includedir: not found Mar 17 08:49:54 MartinH97: in recipes, it's curly-brackets, not parenthesis around variables, i.e. ${D}${includedir} is where you should install your header Mar 17 08:50:14 MartinH97: includedir in your Makefile looks wrong, seems DESTDIR is also not set correctly Mar 17 08:51:16 MartinH97: or let's say, not wrong but different from the includedir from Yocto PoV (/usr/include) Mar 17 08:53:00 qschulz what is the right way to install a header of a kernel module from its makefile (ignoring all Yocto for the moment) Mar 17 08:53:55 MartinH97: I should have started with this question: what exactly do you want to do? What's the use case for this header file? Why does it exist :) Mar 17 08:55:08 Hi, how should i normally manipulate config files? I need to reconfigure systemd-journal. Mar 17 08:55:38 qschulz good point;-)  I want to compile and install an external kernel module including its header file. The header file shall be available to other recipes and to SDK. My current kernel module makefile does not yet install the header. Mar 17 09:00:13 I tried a bbappend and installed my own config file. But this does not work, its still the original conf file Mar 17 09:07:26 GeneralStupid: an append with prepending the file path is the usual way. if it is not being picked up, you might need to dig deeper (and check that the file actually is being puled in from somewhere, instead of being created) Mar 17 09:08:42 LetoThe2nd: Ok, so i have to take a deeper look. Thank you Mar 17 09:09:10 GeneralStupid: have fun! Mar 17 09:12:52 GeneralStupid: also triple check it's really FILESEXTRAPATHS_prepend := in your bbappend, it's common to have typos :) Mar 17 09:13:33 MartinH97: What I would recommend is to have a simple recipe which only give the header file. Then this "header" recipe would be added to your module recipe via DEPENDS, and you could install it in your SDK too Mar 17 09:14:12 MartinH97: the split from your kernel module recipe is not per-se required but it probably makes more sense from a logical standpoint Mar 17 09:15:33 MartinH97: basically, what I'm going for right now, is that installing the kernel header file from your kernel module from its Makefile seems wrong, because that's very unusual (modules_install installs the .ko and depmod and all, but no header file since it's not needed on the system) Mar 17 09:16:12 qschulz: interesting suggestion! I was drifting of into researching how to support "make headers_install" from my modules Makefile, but didn't find a clean solution yet. Mar 17 09:38:44 qschulz: thanks for the input! a simple do_install_append() fixed the issue so that the header file is now included to sysroot and SDK. Sometimes a second pair of eyes is very helpful! Mar 17 09:40:31 MartinH97: that's what we're here for, happy that we could help you :) Mar 17 09:41:43 Other question O:3  what is the correct way to add kernel headers (headers only!) to the SDK. There is a lot of chatter on the mailinglist documented, like kernel-devsrc, but what is the current up to date solution? Mar 17 09:58:40 qschulz: speak for yourself. i'm not happy. Mar 17 10:06:27 LetoThe2nd: sorry you feel this way, you'll have better days. /me offers a virtual hug Mar 17 10:07:54 can't you offer a fix why kas-docker in lxc b0rks here? ;-) Mar 17 10:09:53 Hi guys, I want to archive some artifacts with a custom .bbclass started once the build of my image is done. I am trying to retrieve the path of .config file of PREFERRED_PROVIDER_virtual/kernel. Mar 17 10:10:42 LetoThe2nd: I prefer to send a virtual beer to help you cope, can't offer better :/ Mar 17 10:10:50 ebail: apply yocto chant #1:) Mar 17 10:10:55 qschulz: hrhr Mar 17 10:11:11 :) Mar 17 10:11:38 I am looking on STAGING_KERNEL_DIR varialbe but it is not pointing to my Kernel build dir Mar 17 10:12:23 ebail: recipe data is local, you cna't access it from your image recipe since the image recipe is in fact... a recipe Mar 17 10:13:21 yes qschulz that is the reason of my question. Mar 17 10:13:47 ebail: the possible way to do that would be to create (or append to) deploy tasks in recipes you want artifacts from Mar 17 10:14:06 qschulz: I am using a bbclass so I might add a task Mar 17 10:14:09 and from your image recipe, get the files from the DEPLOY_DIR_IMAGE Mar 17 10:14:40 ebail: if the class is inherited in the image, #1 still applies nonetheless. Mar 17 10:14:41 ebail: the class will need to be added to each recipe you want artifact from, not sure a class would scale actually, might be better off with bbappends Mar 17 10:15:21 RP: abelloni asked me to take a look at bug 14268. Have you an idea of when it happened, to find the swatbot log? Mar 17 10:15:56 if at all then you need two classes. one exporting the data as qschulz said, being added to all kernel providers, and another one picking everything up, added to all images :) Mar 17 10:16:11 qschulz: Note: I don't need to embed the artifacts (ex: .config) in my image. Mar 17 10:16:48 yes LetoThe2nd I have no choice to export my.config in my Kernel recipe Mar 17 10:17:00 will do that ;) Mar 17 10:17:47 ebail: have fun Mar 17 10:18:03 Thanks. And cheers / prost / santé ;) Mar 17 10:18:29 i'm not as think as you drunk i am! ;-) Mar 17 10:19:11 am neither I Mar 17 10:32:24 RP: I'm getting errors due to "do_package in both covered and notcovered." I first saw it when building with our layers included and thought it was something we were doing, but today I got it when building with only layers from OE-Core and OE. I seem to get it for some random set of recipes (at least there is nothing obvious about the recipes that Mar 17 10:32:24 gave the errors). Mar 17 10:41:07 Saur|Home: that sanity check was added recently and means bad thing are going on :( Mar 17 10:41:40 Yeah, I know. The problem is that I don't know what those bad things are and what to look for... Mar 17 10:43:18 Saur|Home: I don't really know what to advise. The output from -DD is helpful and looking at the messages around the point this task is added to "covered" and "uncovered". Obviously one of the additions isn't right, question is which bit of the code it is hitting Mar 17 10:43:52 Saur|Home: if you can reproduce it with a -DD log, I'm happy to take a look Mar 17 10:46:20 Saur|Home: was pseudo-native unavailable and the hard dependency code kicked in? Mar 17 10:46:30 The mention of do_package makes me suspect that Mar 17 10:49:31 RP: It seems to have built pseudo-native in the build that had errors, if that was what you meant? Mar 17 10:51:04 Basically, what I did was to update poky and meta-openembedded to latest and rebuilt. Last time I had done that was a week ago. Mar 17 10:53:10 Saur|Home: did it skip setscene for the covered/uncovered tasks due to pseudo-native being missing? Mar 17 10:53:32 How can I tell? Mar 17 10:54:06 Saur|Home: the logs, not sure if the log level would be high enough or not Mar 17 10:54:40 Saur|Home: A while ago I was basically overruled about whether we should have noisy useful logs so we do on the autobuilder, we don't elsewhere :( Mar 17 10:57:38 RP: Well, I would love more logging in the tmp/log/cooker/ files as long as I don't get all that in the terminal while running bitbake. Would that be possible? Mar 17 11:00:36 Hi, how to tell bitbake to use specific u-boot version (or maybe a branch or commit) ? Mar 17 11:02:16 medaliyou: by providing a recipe for it. if you have multiple recipes, PREFERRED_VERSION and PREFERRED_PROVIDER can be used to select. Mar 17 11:02:43 medaliyou: and no, you can#t just set UBOOT_VERSION_I_WANT = "xxx.yy" somewhere. it doesn't work like that. Mar 17 11:08:56 Saur|Home: anything is possible. With the current codebase it isn't practical Mar 17 11:09:50 RP: Too bad. It would have been useful to be able to get the full log after a failed build, without having to watch them when building normally. Mar 17 11:10:32 Saur|Home: its something I'd like to change/fix Mar 17 11:11:05 Saur|Home: one challenge is that in most automated builder environments it is the console output which ends up easiest to save Mar 17 11:11:17 but we already know how to adjust that Mar 17 11:11:51 RP: Another thing: the "SOURCE_DATE_EPOCH value from sstate '0' is deprecated/invalid." warning. Is it really useful for anything? It doesn't give any useful information, e.g., what recipe or file was at fault. So based on the warning, there is nothing I can do to avoid it. Mar 17 11:16:18 Saur|Home: that should disappear over time and is mainly a sign that your environment hasn't quite moved forward yet Mar 17 11:16:36 Saur|Home: if that doesn't disappear, we have a problem Mar 17 11:17:23 Saur|Home: the fact it isn't easily traced is a different problem, it is warning of something which should not happen Mar 17 11:17:38 I know it should, but since I cannot do anything to prevent the warning, it doesn't seem useful. To me it is just noise. Mar 17 11:18:33 Saur|Home: you could debug it and find out why it is happening? Mar 17 11:18:55 How? Mar 17 11:19:11 Having signs that something is wrong is probably better than having no evidence at all and things just silently breaking Mar 17 11:20:09 well, figure out which task it is coming from? I'm not seeing the warning here and I don't know of any system which is. I'd have thought it'd be in some task logs files somewhere so grep for it maybe? Mar 17 11:20:30 maybe improve the warning message so it can be traced? Mar 17 11:21:13 The fact it doesn't have a task prefix is a little strange in itself as task based log messages should have Mar 17 11:21:39 but I am pretty blind here as I don't know what you're seeing other that what you've pasted above which could mean several things :( Mar 17 11:22:19 LetoThe2nd Can i do it from a bbappend in a custom meta layer ? Mar 17 11:24:28 Well, all I get is "WARNING: SOURCE_DATE_EPOCH value from sstate '0' is deprecated/invalid. Reverting to SOURCE_DATE_EPOCH_FALLBACK '1302044400'" so there is not much to go on. It is very possible that it, as you say, is just something that will go away over time. E.g., I have not built in this particular build tree for over a week, and not much Mar 17 11:24:29 before that either. Mar 17 11:25:51 Saur|Home: if it was an existing build then it is possible things aren't cleanly updating, I really don't know Mar 17 13:25:47 is it not true that, to do just about anything, yocto/poky has to build or some obtain cross-tools (assembler, linker, compiler, etc.) for the target architecture? Mar 17 13:26:35 if so, then which recipe is responsible for this? Mar 17 13:29:54 is there a way i can find out for myself? i.e., is there a way to cause bitbake to emit an ordered (prioritized) list the recipes/tasks it has built in its task queue? Mar 17 13:32:59 i am working with a new machine architecture which has never been built under yocto, that i can tell, and as i see it this must be the first step Mar 17 13:34:00 yates: have a good look at recipes-core and recipes-devtools. and for example at meta-risc, as thats essentially what it does: inject a completely new ISA. Mar 17 13:34:41 ok thanks LetoThe2nd Mar 17 13:39:50 LetoThe2nd: i cannot find meta-risc. where are you seeing this? Mar 17 13:40:11 did you mean meta-riscv? Mar 17 13:40:21 yates: yeah. Mar 17 13:56:44 is "inherit" == "INHERIT"? Mar 17 13:56:55 * RP notes his plan to remove stale sstate has flaws :( Mar 17 13:57:14 RP: dental flaws? Mar 17 14:03:02 yates: no, thankfully not :) Mar 17 14:11:25 yates: INHERIT is inherit applied to all recipes Mar 17 14:11:27 IIRC Mar 17 14:13:11 LetoThe2nd: drilling down a bit, it appears the main workhorse is the cross-canadian.bbclass class. it looks like it's responsible for AR, AS, GCC, etc. am i on the right track? Mar 17 14:17:14 yates: anything cross canadian sounds like a good start, yes. Mar 17 14:17:24 I just found out that, if you want to change systemd configuration you need to append to systemd-conf.bb not systemd.bb. Mar 17 14:41:23 can we add a txt file from the image recipe? like cat >> ${IMAGE_ROOTFS}/foo? Mar 17 14:41:42 vdl: in the correct tasks yes Mar 17 14:42:12 vdl: look at the rootfs-postcommands.bbclass iirc Mar 17 14:43:36 abelloni: RP: just trying to do some swat this morning, is "AUH" builds part of swat? Mar 17 14:43:58 sgw: no Mar 17 14:45:23 Hello! Mar 17 14:45:23 Im kinda stuck. My yocto builds wrong libunwind recipe (from layer meta), when i want to build from (meta-qti-bsp). Mar 17 14:45:24 `bitbake-layers show-layers` shows priorities: Mar 17 14:45:24 meta-qti-bsp 17 Mar 17 14:45:25 meta 5 Mar 17 14:45:25 any ideas what else may be wrong? Mar 17 14:55:29 Blackbetty: look for PREFERRED_VERSION_libunwind variable, maybe it's set? Mar 17 14:55:42 RP: looks like the other failure seems to be a cascaded failure from a filesystem issue (read-only) Mar 17 15:03:19 sgw: yes, sounds likely. I think that worker was paused and repaired Mar 17 15:23:02 Blackbetty: or the one from meta provides something which the version from meta-qti-bsp doesn't and something depend on this, I usually add PNBLACKLIST to the one which you don't want and it will usually show what was requiring the wrong one to be built (if it isn't as simple as P_V being set as mentioned before) Mar 17 15:34:46 qschulz: didnt find anything with grep Mar 17 15:36:57 setting PREFERRED_VERSION_libunwind="1.0" selects the desired recipe though Mar 17 15:44:16 ok, the problem is visible also with other recipes, for some reason the layers priority doesnt work Mar 17 16:12:46 is there a recipe to buld just the "toolchain", i.e., the base (cross-) assembler, linker, gcc, libc, etc? Mar 17 16:12:52 build Mar 17 16:13:33 yates: meta-toolchain. (didn't you ask that a couple of times already?) Mar 17 16:14:32 LetoThe2nd: yes, you are right. just double-checking Mar 17 16:16:32 yates: i have to admit that i already think twice usually before i type something into your direction. double-checking this way in is essentially willfully wasting the time of people who are helping you out for free here, because you expect them to answer (again). have to admit more, will thinkthrice before typing now. Mar 17 16:19:09 LetoThe2nd: i apologize for that - i never meant to waste your time. the problem is on my side - sometimes if i can't see the destination i want to reach i backup and re-affirm my assumptions Mar 17 16:21:04 to be explicit, in this case, i have forgotten, or at least misunderstood, the role the classes play and did not realize that, apparently, the main work (at least for the default poky builds) is done by meta/classes/populate_sdk_base.bbclass Mar 17 16:21:50 i am relearning yocto/poky - worked with it quite a bit 2-4 years ago.. Mar 17 16:22:11 i've forgotten more than most people ever know about yocto... Mar 17 16:26:13 LetoThe2nd: peace, brother? Mar 17 16:27:36 i am peaceful, just trying to make you think. and i kind of doubt your last claim, to be honest. Mar 17 16:28:04 anyways. this day is over for me Mar 17 16:28:11 have fun y'all Mar 17 16:29:28 most people have no idea what yocto is, so that bar is pretty low Mar 17 16:29:54 can confirm, have a yocto, still learning Mar 17 16:30:04 Spooster: +1 Mar 17 16:49:04 After switching to wayland/weston. It appears that /usr/bin/sudo just "went away" *gestures wildly Mar 17 16:49:41 I'm guessing something in X was previously depending or pulling that down... but am I missing something simple or immediately obvious? Mar 17 16:50:34 Spooster: I would guess your hunch is correct Mar 17 16:57:40 I'm not really sure how to best search the breadth of recipes available to figure out where /usr/bin/sudo was coming from... I guess I could try parsing the dependency graph of x11-base and x11-sato to see if anything jumps out at me... Mar 17 16:58:03 I can revert to my inner caveman and `grep /usr/bin/sudo -r .` and see what pops up Mar 17 16:58:26 Is there a bitbake feature here that helps me? Mar 17 16:58:40 mini-x-session pulls in sudo Mar 17 16:58:49 if you want it, just add it to your image Mar 17 16:59:20 I likely don't want mini-x-session... but... I mean... I'm not going to be surprised there's a recipe just called `sudo` here... Mar 17 16:59:30 yes, there is a recipe called sudo Mar 17 17:00:05 https://layers.openembedded.org/layerindex/branch/master/recipes/?q=sudo Mar 17 17:00:07 oe-pkgdata-util would tell you where it came from if you have the build Mar 17 17:00:17 if you're in the image and have package-management installed, you can query the package manager Mar 17 17:00:27 bitbake -g will tell you what recipes go into building the image, etc Mar 17 17:00:30 there are options Mar 17 17:00:35 and yeah, layer index is awesome Mar 17 17:01:10 rburton: i kind of wish there was a way to contribute pkgdata information to the layer index in some fashion, to make it possible to search runtime package names and target paths Mar 17 17:01:10 Ooo, I think layerindex was what I was hoping to find! Mar 17 17:01:19 kergoth: yes Mar 17 17:01:33 there was the plan of just doing a build with qemux86 to at least get the basics in Mar 17 17:01:36 obviously it'd vary with build configuration and stuff, but even if it could gather the info in *some* way and flag it Mar 17 17:01:41 ah, yeah, that'd do Mar 17 19:06:24 for the image-container.bbclass, shouldn't we set hostname_pn-base-files = "" as the doc states "Having no default hostname in the filesystem is suitable for environments that use dynamic hostnames such as virtual machines." Mar 17 21:29:17 is there a specification or description of .bbclass files? for example, i see common python-type functions "def populate_sdk_command(d):" and also other thingies lime "fakeroot python do_populate_sdk() {...} Mar 17 21:29:28 s/lime/like Mar 17 21:29:47 googled around and did not see this anywhere obvious Mar 17 21:32:21 did you try https://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html#bitbake-user-manual-metadata Mar 17 21:32:55 def and python are subtly different for historical reasons but are just ways to write python functions Mar 17 21:36:55 rburton: ok, but what is "xyz python abc() {...}"? as in "fakeroot python do_populate_sdk() {...}"? Mar 17 21:38:03 line 171 of poky/meta/classes/populate_sdk_base.bbclass Mar 17 21:44:17 yates: fakeroot flags the task to be run under fakeroot/pseudo. it literally just sets a flag 'fakeroot' to 1 on the task in the metadata, same thing the python keyword does Mar 17 21:46:40 hi I don't understand the rule of pn in hostname_pn-base-files = "mybox" ... can you explain me ? Mar 17 21:53:05 hey, can I add a recipe to my system without having to building the image again? Mar 17 22:07:25 McAwesome: You can build build a package (ipk, deb, rpm) and install it if the tools are on the image Mar 17 22:07:54 McAwesome: I'm... not sure how, we build read-only images so it's always a full update to change it, but I know it's possible Mar 17 22:19:06 JPEW thanks for thw quick answer, do you know how can i know what packing mechanism does my system use? Mar 17 22:20:28 McAwesome: Check the `PACKAGE_CLASSES` variable Mar 17 22:20:44 bitbake -e | grep ^PACKAGES_CLASSES= Mar 17 22:21:28 McAwesome: It doesn't really matter *which* one you are using, it would only affect which tool (dnf, apt, opkg) you would use to install the package Mar 17 22:21:57 McAwesome: Bitbake will build a recipe to match whatever your system is already using (unless you change it) Mar 17 22:26:56 JPEW bitbake -e | grep ^PACKAGES_CLASSES= gives no output Mar 17 22:27:46 JPEW after installing opkg how can i then add glew for example without having to re-build the image? Mar 17 22:32:16 McAwesome: I think you can copy over the ipk file and use opkg to install it Mar 17 22:32:32 After you have built glew from a recipe of course Mar 17 22:33:28 McAwesome: I think that you can also tell bitbake to make a valid package feed that you could server over HTTP and have the target pull from it.... but I'm not sure on the details Mar 17 22:39:53 sorry for my newbie questions but what do you mean built  glew from the recipe?  @jpew Mar 17 22:44:04 like I can see the recipe file and download it from the sources Mar 17 22:57:22 JPEW **** ENDING LOGGING AT Thu Mar 18 02:59:56 2021