**** BEGIN LOGGING AT Fri Apr 17 02:59:57 2020 Apr 17 08:43:23 If i want to use a defconfig which is available in my kernel branch, how can i tell yocto to use this config? Apr 17 08:51:14 PatrickE: I think https://www.yoctoproject.org/docs/latest/kernel-dev/kernel-dev.html#using-an-in-tree-defconfig-file has the info you need Apr 17 08:51:37 Thanks i will try it Apr 17 08:56:41 ERROR: ParseError at /home/user/devel/app/company/meta-company-imx6/recipes-kernel/linux-imx_%.bbappend:12: unparsed line: 'KBUILD_DEFCONFIG_KMACHINE ?= app_imx6_defconfig' Apr 17 09:10:58 PatrickE: you need to add double quotes around app_imx6_defconfig => "app_imx6_defconfig" Apr 17 09:32:09 hello all ! I have 2 recipes, recipe2 depends of recipe1. The question is how to pass some output file from recipe1 to recipe2 ? :) Apr 17 09:50:04 Hi. I would like to create a new selftest unitest in Yocto and my test uses a python package (fdt). How can I make sure that that package will be installed in the environment where the test is running. Is the python3-manifest.json file the answer? Apr 17 10:10:07 Hello. On a local project and just for fun I am trying to update a qemu recipe (on poky) to a different version. I took the qemu recipes from warrior and put them on thud (removing the original qemu recipes). when creating a standar sdk everythin works execpt that the installer creates two /opt/poky directories (one of them is /opt/poky-some-shit). Apr 17 10:10:41 Just for the fun of hacking things while on quarantine.... does anybody knows why is this happening? Apr 17 10:31:49 interruptguy: no, the python3-manifest controls how the python3 recipe itself splits the packages Apr 17 10:32:28 interruptguy: what sort of unittest are you talking about specificailly Apr 17 10:32:30 rburton, thanks. How should I handle the python dependencies for Yocto tests? Apr 17 10:34:37 I've added a new class (in on the mailing list fit_image.bbclass) and I'm working on creating a unitest for it. The unitest is located in "poky/meta/lib/oeqa/selftest/cases/" Apr 17 10:35:08 your test can just bitbake stuff it needs to be built Apr 17 10:35:32 I want to test the FDT blob generated and `fdt` module seems perfect for that Apr 17 10:38:29 rburton, I have a bit a problem to understand how can I make this module available for my test. You're saying that I should add a recipe for python fdt package and build it natively as a dependency on my recipe that the test is using it? Apr 17 10:39:54 have a recipe, bitbake it natively, and then call python3-native with a script that imports ftd Apr 17 10:40:25 rburton, just testing the bitbake output from using the class will only test a part of the functionality. I want to be able to test also the content of the FDT blob. Apr 17 10:44:12 rburton, thanks...I'm not fully understand :) (some example will be great), but I think I can work with the tip that you gave me ... I will try to come back if I need more help :) Apr 17 10:54:26 Ninic0c0: I think the correct way to do this is to make recipe1 populate the sysroot with the files required by recipe2 Apr 17 11:14:33 qschulz: I did some further debugging on that mutlilib issue and its turned into a disaster :( Apr 17 11:15:45 qschulz: taking alsa-plugins as an example, PACKAGES references PACKAGECONFIG which references DISTRO_FEATURES and DISTRO_FEATURES gets set up in anonymous python so the multilib code can't find it at the time it expands PACKAGES :( Apr 17 11:18:01 New news from stackoverflow: Recipe compilation fails due to Floating Point Unit compatibility issue (I assume) Apr 17 11:24:28 rburton: getting back to OE_CMAKE_TOOLCHAIN_FILE, looks like it was introduced with 034ee07ed9b2e88272a010dbbdb685c293c09375 which is thud+ ... we're still sitting on rocko here ... I'll try to pick that change and hope it's that easy or do you know of any specific reason why it didn't make it into rocko? Apr 17 11:42:24 nameclash: because its not a bug fix so doesn't get backported Apr 17 11:42:50 nameclash: you know rocko is EOL right Apr 17 11:42:58 https://wiki.yoctoproject.org/wiki/Releases Apr 17 11:47:44 rburton: no I didn't, I knew it was old but not EOL, thanks for the heads-up. I'll continue pushing for an upgrade... :-/ Apr 17 13:08:00 qschulz: http://git.yoctoproject.org/cgit.cgi/poky-contrib/patch/?id=ea3562dd74db6521beffd67b085b70ec04e28700 is some of the other fallout. Getting a bit too horrible :( Apr 17 13:48:27 New news from stackoverflow: Unable to put lapack.so file inside rootfs Apr 17 15:26:55 RP, do you think http://git.openembedded.org/openembedded-core/commit/?h=4292387ef6c4e80428bad6a07c844a288b27d9a1 could be applied to zeus as well? Apr 17 15:43:46 shoragan: I think it could be, needs to be suggested to Anuj/Armin Apr 17 15:46:13 ok, thanks Apr 17 15:47:05 ah, i was confused by your committer entry in the poky repo Apr 17 15:51:56 armpit, do you take suggestions via IRC or prefer email? Apr 17 16:01:51 Hello friendly folks. If I have software package A which is a framework (and contains bbclasses for applications built with it) and I have application B for target B_PC and application C for target C_PC that are dependent on framework A, how should I structure these into recipes/layers? Apr 17 16:02:00 At the moment, I have included B in the layer for A because they are related software. But the recipes for B will want to do things like set the hostname for B_PC via a bbappend. Is it more usual to put everything for B and for C into two separate bblayers, or to somehow only activate the bbappend if my local.conf adds package B to IMAGE_INSTALL? Apr 17 16:02:26 Otherwise .bbappends related to B and C will clash. Apr 17 16:08:17 incidentally, https://www.yoctoproject.org/irc/ is not a link that leads to the channel logs (any more?); it redirects to https://bugzilla.yoctoproject.org/irc/ which returns 404 Apr 17 16:08:33 shoragan: we have different maintainers to look after the stable series Apr 17 16:12:39 http://logs.nslu2-linux.org/livelogs/yocto/ is a currently available set of logs Apr 17 16:13:52 halstead: Should https://www.yoctoproject.org/irc/ work? Apr 17 16:17:26 ChrisStuart: in answer to your question, perhaps you should have two images, one which includes B and one which includes C and those image recipes could adapt the images as appropriate? Apr 17 16:17:57 One layer due to the dependencies sounds ok. You should avoid anything in local.conf though Apr 17 16:22:39 Yes that sounds like a more sensible arrangement. Apr 17 16:23:37 Thanks :) Apr 17 17:31:29 Hello..I have an image based on core-image-minimal. I generate image for target and also qemu. When I PXE boot the target using rootfs from target build, after the boot, I get presented a login prompt. Per my understanding (based on the fact that when I burn the hddimg to target) the root user does not have any password and that after I type the Apr 17 17:31:29 root user username, I should be logged in. However, I m presented a password prompt when I m using rootfs (core-image-minimal-PLATFORMINFO.ext4). Apr 17 17:32:06 root user login is only allowed if debug-tweaks is enable din your IMAGE_FEATURES. Apr 17 17:32:15 However when I PXE boot target using rootfs generated for QEMU (core-image-minimal-QEMU.ext4), I get logged in after entering root user name Apr 17 17:33:11 @fray for the same image when I burn the .hddimg to target, I am able to login without password for root user. Apr 17 17:33:19 not sure then Apr 17 17:36:24 also @fray where can I find debug-tweaks Apr 17 17:37:12 set it in your local.conf Apr 17 17:37:30 implementation locals very.. look in the classes and image recipes Apr 17 17:38:39 I see that this exists in my local.conf Apr 17 17:39:04 EXTRA_IMAGE_FEATURES ?= "debug-tweaks" Apr 17 17:40:04 I wonder if this (no password root login) is due to some failed systemd services on bootup using PXE boot Apr 17 17:41:00 yup Apr 17 17:41:10 as for why it's not working, no idea Apr 17 17:41:12 can you ever log in on the h/w target ? Apr 17 17:41:50 zeddii If I use the rootfs generated for QEMU (same kernel) then I can login using root user with no password Apr 17 17:42:14 I m trying to understand the difference in the rootfs in both Apr 17 17:42:19 but not sure yet Apr 17 17:49:14 New news from stackoverflow: Is there any short A to Z description of how to debug the Linux kernel that has been tested and contains ALL necessary steps ? Esp. for Yocto? Apr 17 17:59:34 heh, seems like poor yocti is digging the bottom of the barrel for quality questions. Apr 17 18:00:11 ...and yet I'm half tempted to click just to see what kind of bikeshedding it trolls in. Apr 17 18:00:30 * paulg blames the isolation. Apr 17 18:00:38 paulg, A - starting adding printks.. B - add more printks.. ... Z - give up Apr 17 18:06:23 fray, Toss it over the wall to a kernel developer. :) Apr 17 18:06:56 ya, that was kind of what I was thinking.. really requires experience and specialized knowledge.. Apr 17 18:07:17 the only 'tough' kernel problems I've debugged were found by inspection and specialized tools.. not general "do this" type behaviors Apr 17 18:22:28 RP, I've tracked down and repaired the bad redirect. https://www.yoctoproject.org/irc/ is available again as expected. Apr 17 18:43:41 halstead: thanks! Apr 17 18:46:39 fray, I think the post was from jwessel - just trying to troll us. Apr 17 18:47:02 who else would use kgdb over serial? ;-) Apr 17 18:48:32 lol Apr 17 18:49:02 paulg: I think I'm going to look at many mailing list questions in a new light now! Apr 17 18:51:26 I support paulg's theory. Apr 17 18:51:59 paulg, I have but I didn't do it. :) Apr 17 19:02:43 paulg: A post from where? Apr 17 19:03:38 jwessel, the stack overflow link that yocti posted about 15 lines up and about 1hr ago. Apr 17 19:03:45 * jwessel looks Apr 17 19:04:15 I am not sure if we have something formulated specifically for the YP. Apr 17 19:04:47 I much prefer using simulators vs trying to debug the real hardware. Apr 17 19:05:45 * paulg resembles fray 's "sprinkle printks everywhere" example. Apr 17 20:04:02 armpit: you awakeß :) Apr 17 20:37:42 Just wondering, how do you guys compile your Yocto apps (not the Yocto image itself, but the apps you run on Yocto)? No optimization, then strip during build, and keep an unstripped binary around in case you need to debug? Optimized from the get-go? Apr 17 20:54:26 Using a yocto kernel with my own branch (in github). The fetch takes a super long time (and its pretty big). Any support for shallow clone? BB_GIT_SHALLOW ?= "1"BB_GIT_SHALLOW_DEPTH ?= "1" does not seem to help Apr 17 20:55:05 on zeus unmodified Apr 17 21:10:01 Also looks like the yocto kernel requires a git repo? For patches to work and such it uses git am. Apr 17 21:55:13 LetoThe2nd, what day is it? Apr 17 22:05:40 in the case where you have different products (aka different packages of applications) would those usually end up being different images? Apr 17 22:06:25 (new to yocto, trying to figure out how to best organize a project) Apr 17 22:07:04 yes, that would be a good way to do things, unless you want to install stuff at runtime. Apr 17 22:08:19 gotcha, okay. There shouldn't be a need to install stuff at runtime, except for maybe during debugging **** ENDING LOGGING AT Sat Apr 18 02:59:57 2020