**** BEGIN LOGGING AT Wed Oct 12 02:59:58 2016 Oct 12 06:48:08 morning all Oct 12 06:48:40 is it possible to detect in a recipe that bitbake was invoked with -v ? Oct 12 08:37:28 I'm trying to add a new "sdimg" image type to image class (derived from core-image-x11) - created IMAGE_CMD_sdimg and added it to IMAGE_FSTYPES, but the image_sdimg target still does not appear, what am I missing ? Oct 12 08:38:41 (nm, it works when I'm looking at the correct image class) Oct 12 08:48:21 yann|work, please also explain why your original expectations weren't met Oct 12 08:49:25 redengin: there was no problem, I had added defs to one image recipe and looking for it an another - sorry for the noise Oct 12 08:50:21 yann|work, cool Oct 12 09:05:35 I need to get $GRUB_CFG to build my image, what's the target I need to depend on to get it ? Oct 12 09:12:09 yann|work: don't know off the top of my head, but i added a handy recursive search helper to http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#usingpoky-debugging-others Oct 12 09:12:37 grub-efi.bbclass and live-vm-common.bblcass mention GRUB_CFG Oct 12 09:13:21 I'm considering calling build_efi_cfg and efi_populate myself Oct 12 09:14:28 alas, build_efi_cfg is not available from a shell snippet Oct 12 09:15:52 yann|work: https://www.yoctoproject.org/docs/2.2/bitbake-user-manual/bitbake-user-manual.html#bitbake-style-python-functions-versus-python-functions has a tip on how you can mix shell and python within the same task Oct 12 09:16:43 ah cool, thx! Oct 12 09:17:19 check out do_bootdirectdisk() in image-vm.bbclass as well. that one mixes python and shell using the method mentioned in that section. Oct 12 09:17:19 Crofton: you really volunteered to be the official cmake maintainer? Oct 12 09:17:37 Crofton: i hear there were witnesses but i guess the question is where you drunk at the time Oct 12 09:18:24 probably somewhere in Berlin? Oct 12 09:19:30 damnit, 'were' Oct 12 09:28:00 lol Oct 12 09:28:20 I basically update, then make sure gnuradio an duhd build Oct 12 09:28:23 success Oct 12 09:28:40 no, was sober, Oct 12 09:28:52 wish you'd volunteered before i spent two days adding debug statements to cmake's find_package logic :) Oct 12 09:29:01 heh Oct 12 09:29:17 i'm not convinced we're doing cross-compile properly either, there's a few variables that we don't use but cmake insists are for cross Oct 12 09:29:17 you saw my test requirements Oct 12 09:29:23 is it doing something dumb? Oct 12 09:29:38 lol Oct 12 09:29:53 actually i think the bug was due to opencv doing something dumb, but cmake's error is not helpful Oct 12 09:29:53 khem is rating meta-bsps for the number of stars on github Oct 12 09:30:07 cmake is a miserable piece of crap Oct 12 09:30:15 +1 for that Oct 12 09:30:24 also, I have a lead on some other people that care about opencv Oct 12 09:30:29 +1 again Oct 12 09:30:51 we are at the point in koen's talk where people try to clarify his better points :) Oct 12 09:32:12 need a way to help people find others interested in some of these painful packages Oct 12 09:33:24 you're at the AB meeting right :) Oct 12 09:34:22 not yet Oct 12 09:34:26 Koen's talk Oct 12 09:34:31 i mean, you'll be at the AB meeting Oct 12 09:34:35 AB is like 3 PM, TZ dependent. Oct 12 09:35:34 I have days when I just want to walk out the door and find a mountain to sit on Oct 12 09:35:58 i occasionally have days when i don't want to do that Oct 12 09:38:14 He went away from the basement and left this note on his terminal: "I'm going to a commune in Vermont and will deal with no unit of time shorter than a season." Oct 12 09:38:23 best line from a tech book ever Oct 12 09:38:32 ok offline Oct 12 09:45:08 hm, why would I get a ShellSyntaxError on python code in a "python IMAGE_CMD_sdimg() {}" block ? Is there some magic causing the "python" keyword to get ignored ? Oct 12 11:06:56 yann|work: the IMAGE_CMD_* definitions are read as variables and used to insert code into shell functions (like do_image_sdimg) Oct 12 11:07:26 gasp :) Oct 12 11:07:42 ${foo_fn} gets you the body of foo_fn() if it's defined with {} Oct 12 11:07:57 you can see the code in image.bbclass btw Oct 12 11:07:59 no way to call python code from shell ? Oct 12 11:08:21 right, I could have looked for it ;) Oct 12 11:09:02 no clean way that i'm aware of. often you can use a parent helper python function, but that'd be tricky here. :/ Oct 12 11:09:45 might be able to run a python script though, passing it the stuff it needs Oct 12 12:38:55 rburton: hi Oct 12 12:39:03 rburton: any experience with building network-manager? Oct 12 12:39:11 nope Oct 12 12:39:15 ok Oct 12 18:00:41 So I've got an interesting dependency issue: package A has a header A.h that includes B.h . package B provides B.h. Package A doesn't need to use A.h to build, so package B doesn't need to be present. In fact, package B depends on package A to build, so I cant do DEPENDS_pn-A = "B" (as there would be a circular dependency). Oct 12 18:01:21 The issue that arises is that other things use A.h, and thus depend on package A. But because they don't depend on package B, the build isn't likely to succeed. Oct 12 18:01:43 Do I just need to ensure things that need A.h have DEPENDS = "A B"? Or is there some other way to encode this? Oct 12 19:37:20 hello Oct 12 19:37:38 i'm trying to get an install section of my recipe working. Oct 12 19:37:53 earlier I had a do_install() section Oct 12 19:38:35 but i managed to get cmake to build an install section for me. Oct 12 19:38:52 so for my target build, I can do make install afterwards Oct 12 19:39:38 In bitbake, my host still uses do_install, but my target I'm trying to use the inherit make install Oct 12 19:39:46 this seems to work Oct 12 19:40:17 but when I populated my image I got warnings that files were not in my package, QA step warning. Oct 12 19:40:37 lots of confused/overloaded terminology there and no real question Oct 12 19:40:40 share a recipe? Oct 12 19:40:44 I added a FILES sction based upon the target class and the recipe still builds Oct 12 19:40:53 but the overall image fails Oct 12 19:40:54 If you have install(...) rules in your CMakeLists.txt, "inherit cmake" and removing "do_install" should be everything you need Oct 12 19:41:14 https://gist.github.com/netskink/2cd7f2464a4ccc95fb5c3c771ea0a9d7 Oct 12 19:44:18 FILES_${PN}_class-target is the same as FILES_${PN}, because packaging does not happen for native recipes Oct 12 19:44:53 that is good Oct 12 19:44:54 You haven't shared why the overall image fails, though. Oct 12 19:45:53 davis_: generally, you should start with something that doesn't use any _class-foo. The vast majority of packages don't need to special case native vs target. Oct 12 19:45:57 it fails when packaging. give me a sec let me make that change and see what happens. Earlier I was not getting a package log Oct 12 19:46:38 fishey1: I remember that specific case though; in this case he only needs the generators from the -native build, and the target build uses the generators Oct 12 19:46:53 so unless they also want the generators packaged, this may be a valid approach Oct 12 19:48:41 got a special stiuation which requires it. long story, trust me you don't want me to go into it. ;-) Oct 12 19:48:50 the specific error was * opkg_prepare_url_for_install: Couldn't find anything to satisfy 'pcmx'. Oct 12 19:49:32 its building without the class target specifier now, i'll see what happens. Oct 12 19:52:49 Sounds like you don't have a package with that name Oct 12 19:53:29 Which would be expected if you set 'PACKAGES_class-target = "${PN}-dbg"' Oct 12 20:00:12 there could be another problem. I'm removing all the class ref's. I actually left one in for the package. Oct 12 21:08:06 Hi guys, does anyone have experience with building cpp code thats wrapped into python via sip/qmake on yocto? I think I almost have it but am a bit stuck Oct 12 21:09:11 i know I'm supposed to use native sip to generate a .pro file, and then run native qmake on that to cross compile for the target Oct 12 21:09:47 However, when I make the call to native qmake I'm getting an error: Unknown module(s) in Qt: core gui Oct 12 21:09:54 Any ideas how to resolve this? Oct 12 21:18:45 Geoff_: sounds like you forgot to specify a dependency on whatever recipe provides those Oct 12 21:18:57 Note that those would be the target versions of the qt libs Oct 12 23:08:33 sigh, who changed the order of bootparams in runqemu? it used to append, but now the default & machine args come after user supplied bootparams= on the cmdline, so it's impossible to e.g. override the default uvesafb resolution now Oct 12 23:08:46 guessing it got mixed up when revamped recently **** ENDING LOGGING AT Thu Oct 13 02:59:59 2016