**** BEGIN LOGGING AT Fri Sep 28 03:00:02 2018 Sep 28 05:26:36 does bitbake track local git repo state for sstate reasons? Sep 28 05:27:06 maybe, more helpfully, is there a way to see if a recipe's sstate is valid, or, if not, why? Sep 28 06:07:13 here's another anoying bbclass: systemd Sep 28 06:07:30 it references the ${D} directory in its do_package step Sep 28 06:07:39 but ${D} is populated by do_install, iirc Sep 28 06:07:56 if that's skipped by setscene, then it can't find any files and complains Sep 28 06:28:57 derr no i'm wrong, it checks for the presence of the image directory, but it's empty Sep 28 06:33:19 i think this is more qualcom weirdness Sep 28 07:02:44 okay I'm back to thinking there's another issue in package.bbclass Sep 28 07:03:02 specifically this line: populate_packages[dirs] = "${D}" Sep 28 07:03:17 i believe this makes running do_package create an empty "image" directory Sep 28 07:03:30 but many things use the existince of an image directory to gate some behavior Sep 28 07:03:49 eg systemd.bbclass Sep 28 07:07:07 ah yeah, do_package has ${D} in dirs as well Sep 28 07:07:36 that doesn't seem right Sep 28 07:07:44 do_package just depends on populaet sysroot Sep 28 07:07:55 but ${D} is the image directory used by do_install, no? Sep 28 07:08:06 do_package in theory shouldn't reference it at all Sep 28 07:11:40 i guess I'm just so confused how I can even get into this state Sep 28 07:11:48 where populate_sysroot is cached, but do_package is not Sep 28 07:13:04 i guess I can just make do_package depend on do_install Sep 28 07:23:16 i'm so confused: addtask package after do_install Sep 28 07:23:26 something's so not right about this bsp Sep 28 07:38:17 okay, so, as I suspected, the crux of my problem is still this qualcom bbclass Sep 28 07:38:27 it removes the do_install task and replaces it with a do_install_prebuilt task Sep 28 07:38:36 but do_package assumes the existents of a do_install task Sep 28 07:39:04 now, is it possible for a task to be replaced with a different function at runtime? Sep 28 07:39:41 ie I want to run my own do_install, not an inherited one, but only if some criteria is met? Sep 28 10:43:13 Hi all! I have been looking into building a separate dump-capture kernel for capturing crashes (https://www.kernel.org/doc/Documentation/kdump/kdump.txt). The reason I would need to build a separate kernel is because the dump-capture kernel would have a different kernel config. So far, I haven't been able to figure out how I would go about building two kernels. Does yocto support this? If not, what's the best way to support the dump- Sep 28 12:06:02 New news from stackoverflow: create symbolic link in bitbake recipe Sep 28 15:26:17 armpit: Would you be able to pick up 364c4c7d3fc049f2b734a6a235758a75af364ce0 and f163fd8ec4333f32a32c21d867ef56b40e3eadaa on sumo please? Sep 28 15:26:36 which sumo ? Sep 28 15:27:11 Oh, sorry, oe-core/poky. Those SHA-1's are from poky Sep 28 15:27:53 I always get confused if I should list the oe-core SHA or the poky SHA :( Sep 28 15:28:08 either one works Sep 28 15:29:16 Should be: 'rootfs.py: Install -src packages when PACKAGE_DEBUG_SPLIT_STYLE is "debug-with-srcpkg"' and 'package.bbclass: improve -dbg and -src package ordering' Sep 28 15:30:02 JPEW, never list th epoky sha Sep 28 15:49:59 armpit: Thanks! Sep 28 15:50:09 Crofton: I'll try to remember that next time Sep 28 15:58:17 anyone know how to replace a task at run-time? Sep 28 15:58:57 or how to do the following: for task X, take all tasks that depend on X and make them depend on task Y Sep 28 16:37:03 JPEW, Crofton is just cranky Sep 28 16:37:30 jesus Sep 28 16:37:36 I am way more cranky now Sep 28 16:38:00 but in general most people only know oe-core commits Sep 28 16:38:51 Ya, I suppose it makes more sense with the combo-layers thing Sep 28 16:43:56 hi, any doc/help to crete a new arch in yocto ? Sep 28 17:27:25 armpit, RP We're ready to queue more builds now. Sep 28 17:27:47 k Sep 28 17:37:28 I have a set of binaries that (for historical regions) do not get installed to my image, but are downloaded and run later. however, because of this they do not get signed during rootfs. I added the call to evmctl during the build process to sign them then, however the call fails due to permissions. But, when I run the run the build from the devshell manually, it works correctly. any suggestions? Sep 28 17:46:20 christner: you might want to run it under pseudo Sep 28 18:24:32 * armpit Phil Collins, Su-Su-pseudo Sep 28 19:11:25 armpit: :) Sep 28 19:11:50 armpit: have we run compliance scripts against meta-odroid ? Sep 28 19:13:11 I don't recall Sep 28 19:17:04 armpit: ok Sep 28 19:17:30 armpit: thanks for sumo changes, it built ok on odroid-c2 I merged it Sep 28 19:17:41 armpit: can you update patchwork accordingly ? Sep 28 19:17:57 yes Sep 28 19:18:44 I need to run the compliance on meta-security soon so I will add meta-odroid in the mix Sep 28 19:25:43 armpit: great Sep 28 19:25:50 the layer is looking good now Sep 28 19:30:26 well, thanks to you it is Sep 28 20:52:45 does anyone know how the metadata_scm class works? Sep 28 20:52:55 it appears that this automatically invalidates sstate cache entries Sep 28 20:52:59 but I'm struggling to figure out how Sep 28 20:54:55 it seems that info is also printed out when bitbake prints out the layers at the beginning of execution Sep 28 21:17:09 Hi all! I have been looking into setting up dump-capture kernel to record crashes (https://www.kernel.org/doc/Documentation/kdump/kdump.txt). However, this requires building a separate kernel and I am wondering if yocto has support for building two kernels? If not, how do I handle the dump-capture kernel usecase? Sep 28 22:01:42 mtahmed: i suspect you'll have to instrument your kernel recipe with some custom tasks Sep 28 22:01:53 mtahmed: or perhaps a bbclass extension Sep 28 22:02:29 so you'd have a "kernel" package and a "kernel-crashkernel" package Sep 28 22:03:01 similar to how "*-native" packages work Sep 28 22:06:46 @jdel I was also concerned about how the kernel recipes are really tied into everything and everything kind of assumes that there's only a single kernel built. Sep 28 22:07:49 I also saw this RFC and am wondering if it ever got anywhere: http://lists.openembedded.org/pipermail/openembedded-core/2015-April/103662.html Sep 28 22:10:44 And I saw this: https://patchwork.openembedded.org/patch/122765/ but it seems like it never made it in Sep 28 22:13:39 i suspect think the kernel build is not as tightly coupled as you think Sep 28 22:13:52 also, this wouldn't change a normal virtual/kernel dependency Sep 28 22:14:01 it would just add another package in the same recipe Sep 28 22:14:17 if the only thing that changes is the kernel paramaters and/or config Sep 28 22:14:29 that would be easy to use class extension variables to sub in for a crashkernel build Sep 28 22:15:01 And then they would use separate build directories as well? Sep 28 22:15:01 eg PARAMS=foobarbaz; PARAMS_crashkernel=bazbarfoo Sep 28 22:15:06 yes Sep 28 22:15:34 Ohhh I see. Neat idea! I'll give that a shot and report back and potentially submit patches upstream. Thanks @jdel!! Sep 28 22:16:01 glhf Sep 29 00:24:47 @jdel Is there a guide of sorts on how to add a new variant? If I add a new class and just set PROVIDES += "linux-dump-capture", bitbake complains: linux-dump-capture was skipped: Set PREFERRED_PROVIDER_virtual/kernel to linux-dump-capture to enable it Sep 29 00:25:19 Of course I also did BBCLASSEXTEND += "dump-capture" in the main kernel recipe Sep 29 00:25:28 And the class is called dump-capture.bbclass Sep 29 01:11:47 Also, if I have an anonymous python function in a variant class, it doesn't seem to get executed. Sep 29 01:11:57 Is that by design? **** ENDING LOGGING AT Sat Sep 29 03:00:00 2018