**** BEGIN LOGGING AT Wed Jul 06 02:59:58 2016 Jul 06 06:53:03 hi guys, is there any way to have systemd unit files outside std paths? Jul 06 07:02:16 is this a question for #systemd ? Jul 06 07:06:46 c0rnel: actually it can be both systemd & yocto, because atm, i don't really know how to handle it in yocto. it seems that the systemd.bbclass doesn't allow this as it searches for systemd units in hardcoded paths Jul 06 07:12:45 m57n, the problem may be that systemd itself searches for them in hardcoded paths , if i understand correctly what you want to achiev Jul 06 07:12:49 e Jul 06 07:14:32 m57n: what would be the benefit of unit files in non-standard locations? Jul 06 07:16:49 jku: actually i wanted to produced a application partition (instead of a whole rootfs image). This way, i can only have that partition flashed instead, so i wanted to have the associated systemd file inside this partition Jul 06 07:53:06 hi guys, I have a question on yocto and how to enable thumb mode when compiling for it Jul 06 07:53:43 I was always under the impression that having "thumb" in TUNE_FEATURES would be enough to have it compile using the thumb instruction set Jul 06 07:54:06 which seems actually to not be the case because that does not happen unless ARM_INSTRUCTION_SET = "thumb" Jul 06 07:54:13 is this how it should be? Jul 06 07:54:49 florin, do you want only thumb? Jul 06 07:55:14 I want also dsp Jul 06 07:55:25 dsp? Jul 06 07:55:30 so the DEFAULTTUNE is correctly set as armv5te Jul 06 07:55:48 I would assume this would let yocto know that I need thumb mode Jul 06 07:56:28 I am basing on tune-arm926ejs.inc Jul 06 07:56:31 florin, if your processor supports both thumb and armX then it'll tune bot Jul 06 07:56:59 it will tune both? Jul 06 07:57:00 florin_, if you only want thumb then you'll have to force thumb mode Jul 06 07:57:25 so the build config output is Jul 06 07:57:26 TUNE_FEATURES = "arm armv5 thumb dsp" Jul 06 07:57:56 florin_, that just gives the compiler the ability to use thumb as appropriate, not force it into thumb Jul 06 07:58:53 hm, I see Jul 06 07:59:08 are you sure you always want thumb? Jul 06 07:59:44 no, I think I will just have it forced for a particular recipe which is misbehaving Jul 06 07:59:50 | arm-poky-linux-gnueabi-g++ -march=armv5e -marm --sysroot=/home/builder/tmp/build/tmp/sysroots/generic-armv5te '-DV8_TARGET_ARCH_ARM' '-DCAN_USE_ARMV7_INSTRUCTIONS' '-DENABLE_DISASSEMBLER' '-DV8_IMMINENT_DEPRECATION_WARNINGS' '-DICU_UTIL_DATA_IMPL=ICU_UTIL_DATA_STATIC' -I../deps/v8 -pthread -Wall -Wextra -Wno-unused-parameter -fno-strict-aliasing -mfpu=vfp -mfloat-abi=softfp -marm -O3 -fno-omit-frame-pointer -fdata-sections -ffunction-sections -O3 -fno Jul 06 07:59:50 -rtti -fno-exceptions -std=gnu++0x -MMD -MF /home/builder/tmp/build/tmp/work/armv5e-poky-linux-gnueabi/nodejs/5.12.0-r1.5/node-v5.12.0/out/Release/.deps//home/builder/tmp/build/tmp/work/armv5e-poky-linux-gnueabi/nodejs/5.12.0-r1.5/node-v5.12.0/out/Release/obj.target/v8_base/deps/v8/src/api.o.d.raw -O2 -pipe -g -feliminate-unused-debug-types -fdebug-prefix-map=/home/builder/tmp/build/tmp/work/armv5e-poky-linux-gnueabi/nodejs/5.12.0-r1.5=/usr/src/debug/node Jul 06 07:59:51 js/5.12.0-r1.5 -fdebug-prefix-map=/home/builder/tmp/build/tmp/sysroots/x86_64-linux= -fdebug-prefix-map=/home/builder/tmp/build/tmp/sysroots/generic-armv5te= -fvisibility-inlines-hidden -c -o /home/builder/tmp/build/tmp/work/armv5e-poky-linux-gnueabi/nodejs/5.12.0-r1.5/node-v5.12.0/out/Release/obj.target/v8_base/deps/v8/src/api.o ../deps/v8/src/api.cc Jul 06 07:59:56 | In file included from ../deps/v8/src/base/atomicops.h:150:0, Jul 06 07:59:58 | from ../deps/v8/src/base/once.h:57, Jul 06 08:00:00 | from ../deps/v8/src/base/lazy-instance.h:72, Jul 06 08:00:02 | from ../deps/v8/src/base/platform/mutex.h:8, Jul 06 08:00:06 | from ../deps/v8/src/base/platform/platform.h:29, Jul 06 08:00:07 florin_, please use pastebin Jul 06 08:00:08 | from ../deps/v8/src/heap/gc-tracer.h:8, Jul 06 08:00:10 | from ../deps/v8/src/heap/heap.h:15, Jul 06 08:00:12 | from ../deps/v8/src/contexts.h:8, Jul 06 08:00:14 | from ../deps/v8/src/api.h:9, Jul 06 08:00:16 | from ../deps/v8/src/api.cc:5: Jul 06 08:00:18 | ../deps/v8/src/base/atomicops_internals_arm_gcc.h:258:4: error: #error "Your CPU's ARM architecture is not supported yet" Jul 06 08:00:21 | # error "Your CPU's ARM architecture is not supported yet" Jul 06 08:00:23 damn, I forgot, sorry about that Jul 06 08:00:50 http://pastebin.com/HHwb8CQj Jul 06 08:01:33 so I took for granted that thumb in TUNE_FEATURES should force thumb code for all the recipes Jul 06 08:02:15 so when will it use thumb? not sure I understand how that decision is being made Jul 06 08:34:51 redengin, so if DEFAULTTUNE is set to armv5te, the package will fail as in the pastebin Jul 06 08:35:10 unless ARM_INSTRUCTION_SET = "thumb" is set in the recipe Jul 06 08:35:30 or the package compiles if DEFAULTTUNE is set to armv5 Jul 06 08:35:46 without setting ARM_INSTRUCTION_SET anywhere Jul 06 08:35:55 I don't really understand this Jul 06 08:38:27 which v8 rev are you using? on head I don't see an #error Jul 06 08:38:43 florin_: how about comparing the -march and -marm compilation flags in the good and bad case? Jul 06 08:39:32 just to understand if and what is not properly passed from metadata to the job Jul 06 08:39:37 fredcadete, compiling the entire image under thumb doesn't seem tenable Jul 06 08:40:43 fredcadete, the error he is seeing is a pre-processor halt based on the source he's using Jul 06 08:41:59 agreed Jul 06 08:42:06 it's nodejs that was failing to compile https://github.com/imyller/meta-nodejs/tree/master/recipes-devtools/nodejs Jul 06 08:43:11 assuming nodejs does not support thumb, you also say you get different results using DEFAULTTUNE="armv6te" vs using ARM_INSTRUCTINO_SET="thumb" Jul 06 08:43:16 florin_, which revision are you using? Jul 06 08:44:04 fredcadete, I believe he is saying he can only get it to compile under thumb Jul 06 08:44:56 fredcadete, my guess is that his chosen node source didn't understand his arm flags Jul 06 08:45:13 oh Jul 06 08:45:16 I'll shut up then Jul 06 08:46:18 fredcadete, don't shut up, it takes a group to understand user experiences Jul 06 08:46:35 c183271cb2a57295fb3544436bb62e4718c5d25e Jul 06 08:47:17 florin_, how did you find that hash? Jul 06 08:48:12 it's this commit: recipe: prevent file-rdeps and host-user-contaminated QA warnings Jul 06 08:49:21 that's the HEAD of the layer when generating that problem Jul 06 08:49:55 I see master added 2 more commits since then but unrelated Jul 06 08:50:11 florin, do you can you post your full recipe set? Jul 06 08:50:48 what do you mean? it's the recipe as it is there, not changed Jul 06 08:50:59 isn't -march=armv5 -DCAN_USE_ARMV7_INSTRUCTIONS also a bit weird? Jul 06 08:51:22 florin_, what I expect is that your nodejs recipe is pulling in an older head that doesn't support your arm target Jul 06 08:52:12 fredcadete, I agree, the arm7 allowance for and arm5 target is strange Jul 06 08:54:15 fredcadete, I expect that those flags are baked into a sane recipe, rather than what florin is being exposed to Jul 06 08:59:06 since arm is hardware set of platforms, it maybe necessary to tweak the compiler in different ways than a normal platform Jul 06 09:00:06 on a side note, anyone have experience with docker? Jul 06 09:00:55 will try something and get back to you Jul 06 09:01:40 florin, can you give me some context on what you've been given vs what you've customized? Jul 06 09:22:17 redengin, I have some experience with docker Jul 06 09:22:52 bachp, whats the avg startup time for a docker instance? Jul 06 09:23:22 It depends what image you are using Jul 06 09:23:35 I'm looking at using docker as a build container Jul 06 09:25:10 I created a chroot, but I'm ready to change over to docker, but I want to know what startup time looks like Jul 06 09:25:25 It's pretty fast alpine takes less than a second Jul 06 09:25:54 my developers expect instant builds (startup time less than 10's of seconds) Jul 06 09:26:04 We used debian based containers for our bitbake builds and they startup almost immediatly Jul 06 09:26:25 bachp, and do you use docker on Windows? Jul 06 09:26:27 Less than 10 seconds should be more than possible Jul 06 09:26:33 No not yet Jul 06 09:27:11 np, I like *nix Jul 06 09:29:00 bachp, do you know how docker works on windows? I'd expect its much more complicated Jul 06 09:32:00 and do docker instances support non-linux platforms (Windows, OSX) or is that still in development Jul 06 10:04:34 redengin, there is docker support for windows in beta, but it uses MS hyper-v in the background to start docker in a linux vm Jul 06 10:05:09 redengin, but once it is release it shouldn't be more complicated than on linux Jul 06 10:13:08 bachp, agreed, I'm just looking for experiences Jul 06 10:14:06 before I jump in, I want to see where it fails, and where it fails I'll contribute Jul 06 10:29:57 so redengin Jul 06 10:30:08 I have used poky on branch krogoth Jul 06 10:30:24 and https://github.com/imyller/meta-nodejs.git from master Jul 06 10:30:46 using a machine that has: Jul 06 10:30:56 require conf/machine/include/qemu.inc Jul 06 10:30:56 require conf/machine/include/tune-arm926ejs.inc Jul 06 10:31:16 and then just tried to bitbake nodejs Jul 06 10:33:11 the problem is that I get TUNE_CCARGS=" -march=armv5e -marm" Jul 06 10:33:38 I expected this to be march=armv5et Jul 06 10:35:00 but anyway, if the MACHINE uses arch-armv5.inc instead of tune-arm926ejs.inc it works Jul 06 10:40:54 any clue on that? Jul 06 11:01:49 florin_, it looks like nodes/v8 doesn't know about armv5e Jul 06 11:02:47 florin_, see here: https://github.com/nodejs/node/blob/master/deps/v8/src/base/atomicops_internals_arm_gcc.h#L160 Jul 06 11:09:31 yes indeed, problem is that my DEFAULTTUNE is armv5te Jul 06 11:12:22 which nodejs apparently should know Jul 06 11:36:15 so that should not be it Jul 06 11:36:19 florin_: you can always track the origin on TUNE_CCARGS using bitbake -e Jul 06 11:37:04 maybe your bsp layer is overriding defaulttune Jul 06 11:38:10 I did track it with -e and I saw: DEFAULTTUNE="armv5te" Jul 06 11:38:57 that is why I am saying the defaulttune is correct however I have this problem Jul 06 11:40:15 from what I read of the docs (http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#var-DEFAULTTUNE), DEFAULTTUNE is a hint Jul 06 11:40:33 something else in your meta-data is affecting TUNE_CCARGS Jul 06 11:41:09 bitbake -e can show you where TUNE_CCARGS is set and you can work backwards from there Jul 06 11:41:56 I did and ended up at feature-arm-thumb.inc Jul 06 11:42:29 which apparently states that you need ARM_INSTRUCTION_SET set to thumb if you want code compiled in thumb mode Jul 06 11:42:57 however, redengin states that if thumb is in DISTRO_FEATURES, then it will anyway compile code in thumb mode when possible Jul 06 11:43:21 I am having a bit of a hard time understanding the use of ARM_INSTRUCTION_SET, it is not documented Jul 06 11:43:50 what would be the meaning of ARM_THUMB_OPT for example, when it is set as "arm" or when set as "thumb"? Jul 06 11:43:57 what is the difference between these 2 modes? Jul 06 11:45:32 florin_: shouldn't that be TUNE_FEATURES instead of DISTRO_FEATURES Jul 06 11:45:57 I don't really know, I am reading feature-arm-thumb.inc for the first time Jul 06 11:46:51 yeah, typo from my part, it's TUNE_FEATURES not DISTRO_FEATURES, sorry Jul 06 11:48:22 hi Jul 06 11:52:19 is there a way to make a package being a linux partition with yocto? Jul 06 12:01:28 m57n: could you explain a little more ? the question as you state it makes little sense Jul 06 12:01:38 a package is a bunch of file, it can't be a partition Jul 06 12:03:23 Hi, I would like to add some headers on my target, but without providing the whole package (the equivalent of foobar-dev in debian) I see that -dev packages are built, I can include them with dev-pkgs in IMAGE_FEATURES but the regular package comes with it too Jul 06 12:03:30 boucman_work: you are right. actually i was wondering if we could possibly make a partition file from what it was produced with the do_install task Jul 06 12:05:38 not simply... you can probably hack something, but it's not a supported feature Jul 06 12:05:58 mathieu1: erm, in debian the -dev package depends on the regular package, just like in OE Jul 06 12:06:11 maybe look into the whole do_deploy mechanic... i'm not really sure how it works but that's how packages that produce something else than packages work Jul 06 12:06:12 mathieu1: very hard to link against a library if you don't install the library Jul 06 12:07:43 maybe I used the wrong semantics here, but for instance I used to install sqlite-dev on debian, without having the sqlite utilites. Jul 06 12:08:02 libsqlite-dev* Jul 06 12:08:41 mathieu1: thats simply because debian ships sqlite-dev, libsqlite, and sqlite. sqlite-dev depends on libsqlite, but the binaries are packaged separately. Jul 06 12:09:05 oh ok i understand Jul 06 12:09:29 boucman_work: i actually don't know how to do it. i could probably have a task that create a fs file, but i have no idea how to deploy my package files into it without mounting it Jul 06 12:09:38 mathieu1: for a dev package to be useful in the normal case of a library, you need to install the regular package with the library in too. Jul 06 12:10:15 yes, I'll do it this way, it's probably better and I don't have space constraints Jul 06 12:10:50 mathieu1: patches welcome to stop sqlite-dev from depending on the binaries, as they're packaged separately but the rdepends on -dev to sqlite is still present. Jul 06 12:15:38 m57n: mkfs takes a directory as an input, if you point it to the right directory it will create the image with whatever content you want, my question is more "why do you want to do that" Jul 06 12:16:02 because it doesn't really fit with any common usage pattern, and that usually means that there is a better way of doing what you are trying to do Jul 06 12:31:46 boucman_work: just to flash only a partition instead of the whole rootfs. i don't want to a package manager Jul 06 12:32:04 btw, i've never heard about mkfs taking a directory as input Jul 06 12:35:09 option is -d but I can't find it documented except in mkfs -h Jul 06 12:36:52 can't find it as well Jul 06 12:37:14 I do that via specific image types, not via packages Jul 06 12:37:42 (but files in my cases, I have multiple recipes that provide files in multiple partitions, so it can only be done at the image level) Jul 06 12:39:08 m57n: http://pastebin.com/h5UhRvTc <= this is how I do it Jul 06 12:39:20 you need to learn a bit about image types and image creation to understand it Jul 06 12:39:35 and in modern yocto you might want to do the final assembly via wic Jul 06 12:40:03 rburton: you might be interested in having a look at it too, I am not 100% happy with how I did it and I would gladly take ideas Jul 06 12:40:59 the image targets an i.mx6 which needs a specific boot partition, as you will see Jul 06 12:41:18 thanks, i will have a look Jul 06 12:58:43 boucman_work: i didn't get the fact that the native mkfs. was patched to add this option. Jul 06 13:13:14 m57n: is it ? that explains it Jul 06 13:13:34 thx, that mean that I could somehow add a --exclude-dir option, which would be awesome :P Jul 06 13:15:34 yes it is, because the standard one doesn't provide this option. it was probably why i've never heard about it. btw, it's an awesome one, really helps. Jul 06 13:16:18 Upstream-Status: Backport Jul 06 13:16:28 so that's why I have it on my debian :P Jul 06 15:48:16 Hi guys, can anyone help me add the modphp module for apache? i added both apache2 and php, but no module is present. I see in the php.inc recipe the following condition: ${@bb.utils.contains('PACKAGECONFIG', 'apache2', 'true', 'false', d)}; ... but I have no idea what that does Jul 06 15:55:14 Guest72097: it checks if php was configured with apache2 Jul 06 15:55:43 for example the code here: http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-devtools/php/php.inc#n174 will only run if the php recipe has put "apache2" in the PACKAGECONFIG variable Jul 06 15:56:41 And it does, apache2 is in packageconfig, but the testing still returns false .. @fredcadete Jul 06 16:04:55 fredcadete: what I understand is that it's looking whether apache2 is present, and if so, it runs the libphp5.so related commands, am I correct? Jul 06 16:12:59 Guest72097: that's what it looks like Jul 06 16:15:05 Guest72097: apache2 isn't in PACKAGECONFIG by default, the [apache2] bit is the definition of what to do if apache2 appears in the actual value of PACKAGECONFIG Jul 06 16:15:23 (at this point you may want to read the documentation on packageconfig) Jul 06 16:15:49 does anyone have any advice on bringing up a Rpi2 camera over the camera serial interface on a single chip dev board? this is my first time working with yocto but i've been on this task for a few days so i have pretty detailed information on what i've tried Jul 06 16:16:13 (hello, by the way!) Jul 06 16:17:17 rburton: thanks, that was one of my guesses but I wasn't sure. It's the PACKAGECONFIG ??= "mysql sqlite3 imap apache2 \" line that should contain it. also thanks fredcadete Jul 06 16:19:11 [also, please let me know if there is a more appropriate place to ask this question] Jul 06 17:51:32 hi guys Jul 06 17:52:15 I'm porting my layer from dizzy to krogoth and I have a recipe that has a SRC_URI pointing to a file in deploy dir Jul 06 17:52:55 on dizzy, it works fine but in krogoth it is copying the symbolic link instead the file pointed by the symbolic link Jul 06 17:53:23 the commit that changes this behavor is 865d2fef Jul 06 17:53:29 :q Jul 06 17:53:49 so, this change of behavor can be a bug or not? Jul 06 17:54:38 this commit fixes two bugs: Bug 6128 - Incorrect wildcard unpack behaviour in fetcher Jul 06 17:54:38 Bug 6129 - Local directories unpack to a different location than local files Jul 06 17:54:39 Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=6128 normal, Medium, 2.2, paul.eggleton, NEW , Incorrect wildcard unpack behaviour in fetcher Jul 06 17:54:40 Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=6129 normal, Medium, 2.2, paul.eggleton, NEW , Local directories unpack to a different location than local files Jul 06 17:55:10 but this bugs does not complain about copy of a symbolic link instead the real destiny Jul 06 19:18:05 does anyone know how to deal with django exceptions on the administrative pages on a new toaster installation? Jul 06 19:19:35 Question: .. I have a packagegroup that is included in my image. That packagegroups pacakge-depends.dot shows all the expected packages, but the files from some of them are _not_ in my image.. How is this likely breaking for me? It seems counter intuitive. Trying to get firmware included, keeps missing whole swaths. Jul 06 19:19:57 the "toaster settings" page throws an error that says "not all arguments converted during string formatting" and the "layer sources" page throws "unknown layersource type. if you added a new layer source type, fill out all code stubs" Jul 06 20:28:54 WarheadsSE: Find out which package does missing file belong to, you can do a find in packages-split area of the recipe build area which you think should provide it Jul 06 20:38:34 khem: found the problem, apparently, include can silently fail to find a .inc. Jul 06 20:52:05 WarheadsSE: include is weak, if you want bitbake to send an error on missing include then use require Jul 06 20:52:12 its by design Jul 07 01:40:02 question - is there an easy way to add a repository that isn't available on git to a toaster configuration? i've tried editing toasterconf.json but i'm not sure where in the file it goes Jul 07 01:41:01 i have some board support files from NXP that i need to be made available to bitbake but i'm not sure how to add it via the administrator interface nor through editing the json file, since both seem to want to be linked to a git repository Jul 07 01:45:02 wrmrx:what kind of files are these Jul 07 01:45:43 it could be better that you write a recipe for it and hold these files together in a tarball somewhere in your n/w Jul 07 01:45:58 n/w? Jul 07 01:46:29 it's a layer with some machine definitions and some patches Jul 07 01:46:49 as far as metadata goes, if you want to use local layers with Toaster you use the "import layer" function Jul 07 01:47:32 from the toaster ui? doesn't that ask you for a remote repo name? Jul 07 01:50:07 file:///path/to/local/fs might work too Jul 07 01:50:32 as vcs_url? Jul 07 01:51:22 also - currently, i'm putting the entry for the repo on the same level under "layers": [] listed here: http://www.yoctoproject.org/docs/2.0.2/toaster-manual/toaster-manual.html#layer-source-using-with-toaster Jul 07 01:51:36 is that correct or should it be a separate layer source? Jul 07 01:52:10 i'm assuming it should be okay because i put my non-tracked layer in the same folder as meta-yocto and meta-yocto-bsp Jul 07 01:52:40 the actual location on disk is not important (or it shouldn't be...) Jul 07 01:53:33 as long as it's within the scope of "../../" ? Jul 07 01:53:51 (as described by "apiurl" on the top level) Jul 07 01:58:17 i mean, isn't a local layer the procedure through which people might want to work on patches and build through toaster? Jul 07 02:05:25 AFAIK, layers should be specified using an absolute path, that means they can be anywhere Jul 07 02:05:36 ah, okay Jul 07 02:06:27 btw if you have Toaster-related questions that you don't get answers to, you might get more informed responses by posting to the toaster mailing list Jul 07 02:06:36 then, in the example toasterconf.json, why is it that the default apiurl is "../../" and all the layers on that source are relative to that? Jul 07 02:06:40 thanks, i'll keep that in mind Jul 07 02:06:59 I'm not sure I'm afraid Jul 07 02:07:44 i may just return to doin it by hand, i'm not sure toaster actually offers too much that i don't already have besides possibly a visual frontend Jul 07 02:08:02 it may be worth keeping in mind that toasterconf.json is just what gets used to create the database, once it's created you should use the Toaster main UI and/or the Toaster admin interface to configure it Jul 07 02:08:37 ah, okay Jul 07 02:09:12 being able to examine the build output through Toaster is useful, but then you don't need to actually start your builds through Toaster for that (there's another mode where it just collects data for a command-line build) Jul 07 02:11:59 yep, that's where you launch it with source, correct? Jul 07 02:15:02 also -- quick last question -- thanks so much for helping me thus far -- i'm trying to compile yocto with kernel dynamic debug messages turned on, and i've tried a few different things Jul 07 02:16:07 as per this file (https://www.kernel.org/doc/Documentation/dynamic-debug-howto.txt) i see that i'm supposed to enable a flag in the kernel config file, which as i understand it gets built up from many config files throughout the layers Jul 07 02:16:37 so what's the easiest way to just set one flag? i tried writing a patch to add a config fragment, but it didn't seem to work; and the only kernel flag that i can set with bitbake -c menuconfig doesn't give me the level of logging that i want Jul 07 02:19:01 mmm, toast Jul 07 02:22:37 wrmrx: by "the only kernel flag you could set" do you mean CONFIG_DYNAMIC_DEBUG ? Jul 07 02:22:43 wrmrx: which other ones are there? Jul 07 02:24:04 the one listed in menuconfig is just DYNAMIC_DEBUG Jul 07 02:24:28 right, the same thing then Jul 07 02:24:43 so that should work? Jul 07 02:24:50 it should, I don't see any others listed in that document Jul 07 02:25:02 I don't have any knowledge of dynamic debugging in the kernel though Jul 07 02:25:09 i'll give it another shot Jul 07 02:25:11 just going by what I read in that text file Jul 07 02:25:53 alright Jul 07 02:25:53 note that just turning that option on isn't enough according to that, it looks like you actually need to tell it to turn on debug output for individual files at runtime Jul 07 02:26:12 yep Jul 07 02:26:15 however Jul 07 02:26:28 i haven't gotten it to the point where anything is visible at /sys/kernel/debug/dynamic_debug Jul 07 02:26:46 it mounts debugfs ok but the dynamic_debug directory isn't there Jul 07 02:27:18 you may need to talk to someone with actual kernel experience then I'm afraid Jul 07 02:27:58 I can certainly tell you how to determine if that option is really on for the kernel you built though Jul 07 02:29:48 ah that is very useful Jul 07 02:29:51 yes p&ty Jul 07 02:31:42 esp. given that i've been calling menuconfig with the target virtual/kernel and im' not 100% on whether that actually applies to my target, which is for a specific SCM Jul 07 02:44:23 first run bitbake -e virtual/kernel | grep ^STAGING_KERNEL_BUILDDIR= Jul 07 02:44:45 then grep CONFIG_DYNAMIC_DEBUG on the .config file in the directory that reports Jul 07 02:45:19 tytytyty **** ENDING LOGGING AT Thu Jul 07 02:59:59 2016