**** BEGIN LOGGING AT Thu Sep 08 02:59:59 2016 Sep 08 08:07:26 hi guys, I've googled a lot about my yocto-sdk problem without luck, so I am asking here Sep 08 08:10:52 we're developing some custom apps and libraries, which will be part of the filesystem generated using bitbake, in addition to that we have "bitbaked" a sdk Sep 08 08:12:07 that will be used by a 3rd part developer, which is not allowed to use our sources, but instead will use only binaries and libraries as provided Sep 08 08:12:52 but the problem is that the SDK contains, in /usr/src/, all the apps/libs sources Sep 08 08:14:23 is there a simple way to avoid sources of a given package from being installed into the sdk? Sep 08 10:13:09 hi, question: I would like to exclude some source files from the SDK, because the customer shouldn't see them (e.g. the dbg packages have the c files too), what is the best way to achive this? Sep 08 10:13:16 SDK_PACKAGING_COMMAND? Sep 08 10:14:27 do yocto have a way to exclude files in a nicer way? Sep 08 10:16:09 Hello there, I am trying to build an image using yocto. My host machine's cpu has 64 threads, when I start building and it fetches packages, tasks are done using 64 thread, but in compilation it just doing 8 by 8. What should be the reason ? Sep 08 10:16:51 rubiccube, BB_NUMBER_THREADS Sep 08 10:16:59 is different from PARALLEL_MAKE Sep 08 10:17:21 a good result is achieved by PARALLEL_MAKE ?= "-j ${@oe.utils.cpu_count()}" Sep 08 10:17:33 even if somebody tells to use cpu number +1 or whatever Sep 08 10:19:03 LocutusOfBorg: I am newbie, where should add this line: PARALLEL_MAKE ?= "-j ${@oe.utils.cpu_count()}" Sep 08 10:19:15 in conf/local.conf ? Sep 08 10:19:26 yes, the same place as the other one? Sep 08 10:19:32 rubiccube: exactly Sep 08 10:19:46 I usually end up in having both point to the same value :) Sep 08 10:21:52 zero_note: LocutusOfBorg Thank you, I am trying Sep 08 10:22:07 ilker Sep 08 10:22:13 naber ? Sep 08 10:22:39 Will anybody attend to Yocto Developer Day Europe ? Sep 08 10:22:43 TaZManiAc: Sagol abi Sep 08 10:23:21 rubiccube, yw Sep 08 10:23:22 zero_note: LocutusOfBorg Nothing changed... Sep 08 10:23:50 PARALLEL_MAKE := "64" Sep 08 10:23:52 try that one Sep 08 10:23:58 cpu count is the default for num threads and parallel make Sep 08 10:24:04 ilker geldim Sep 08 10:24:18 ne ayak bu salaklar ? Sep 08 10:24:18 LocutusOfBorg: Should I write BB_NUMBER_THREADS also ? Sep 08 10:25:38 rubiccube: its possible that it can only manage 8 because of dependencies Sep 08 10:25:48 ie until glibc is built. you can't do anything else Sep 08 10:26:09 but the default for BB_NUMBER_THREADS and PARALLEL_MAKE is cpu_count() Sep 08 10:26:18 so start by checking what that value actually is :) Sep 08 10:27:15 rburton1: As I said, when tasks are just fetch, It fetches using all threads, I mean fetches 64 packages at a time. So I got, you are right for the dependencies :) Sep 08 10:28:25 Anyway thanks for your help all. Sep 08 10:29:03 bravo Sep 08 10:34:42 And another question, when I build "bitbake fsl-image-multimedia" the fonts are in my application is not seems when I install it to my board. I am adding qtbase-fonts to IMAGE_INSTALL_append, it not finds this package.. By the way I am using the master branch. Sep 08 10:53:36 rubiccube, Sep 08 10:53:50 RDEPENDS_${PN} += "qtbase-fonts" Sep 08 10:53:53 it is a runtime dependency Sep 08 10:54:20 so, pick who needs the fonts and add the dependency in the recipe Sep 08 10:54:22 or override it Sep 08 10:54:37 and use meta-qt5 probably Sep 08 11:02:20 LocutusOfBorg: thank you, Now, when I try to bitbake meta-toolchain-qt5 I got this error qt5/qtconnectivity_git.bb:do_compile) failed with exit code '1' Sep 08 11:02:37 LocutusOfBorg: And lots of undefined references Sep 08 11:07:41 LocutusOfBorg: any idea > Sep 08 12:27:35 Ulfalizer: If I set SUMMARY_${PN}-dev ?= "${SUMMARY} - development files", add ${PN}-dev to OVERRIDES in a copy of bb.data, and run localdata.getVar('SUMMARY', True), shouldn't that always throw an error because it's self-referential? Sep 08 12:28:13 Maybe I'm misunderstanding something here, but that exact thing seems to work on master Sep 08 12:39:48 neverpanic: yeah, seems that should trigger an error. having ${PN}-dev in OVERRIDES sounds weird though. that might break stuff like FILES_${PN}-dev = ..., because it'd incorrectly get interpreted as an OVERRIDES override on FILES. Sep 08 12:41:20 * Ulfalizer did an experiment with FOO_pn-${PN} = "${FOO}", python () { d.getVar("FOO", True) } Sep 08 12:41:38 that triggers "Exception: variable FOO references itself!" Sep 08 12:53:04 hello neverpanic I hope you are doing good Sep 08 12:57:42 Ulfalizer: What I described seems to happen in meta/classes/package_rpm.bbclass 336 and following, though. (link for convenience: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/package_rpm.bbclass#n324) Sep 08 12:59:44 I agree it would break FILES_*, but those variables aren't used in this branch of the code Sep 08 13:00:04 ohh... they're using the OVERRIDES mechanism to handle those variables locally Sep 08 13:00:15 yeah, shouldn't be a problem Sep 08 13:00:20 dunno why it doesn't break with SUMMARY though Sep 08 13:09:29 ok, so I am confused Sep 08 13:09:46 i was talking to kergoth and bluelightning last yesterday Sep 08 13:10:24 i changed around my build and now I have a problem with the files I'm building. Sep 08 13:11:05 i run this incredibly long compiler setup to build a c program but I can not run it. Sep 08 13:11:25 I'm guessing it needs to be run in the context of the compiler's sysroot. Sep 08 13:11:40 so this does not seem to be what I need to do. Sep 08 13:30:05 is there anybod out there? Sep 08 13:41:49 davis: no Sep 08 13:42:32 bummer Sep 08 14:01:39 i have a recipe using autotools. It checks for lsb_release, so i added a dependency on lsb (DEPENDS += "lsb"). But the recipe still can't find lsb_release. Am i missing something? Sep 08 14:03:30 fragfutter: why is it looking for lsb_release? sounds like something that is worth patching out Sep 08 14:04:39 disregarding this valid note, why is the package lsb not installed in my sysroot during buildtime? Sep 08 14:04:50 if you depends on it, then it is Sep 08 14:05:50 oh, the target sysroot strips out /usr/bin as you can't run anything anyway Sep 08 14:05:59 * rburton1 thinks Sep 08 14:06:00 * rburton1 checks Sep 08 14:14:33 hm. now that i think of it. How should autotools work, are they using the build-hosts programs during configure? Sep 08 14:19:41 mix of host and native sysroot Sep 08 14:20:34 and configure knows to look in the target sysroot for libraries etc Sep 08 14:32:53 hmm.. something is setting -Werror and i don't know what :( Sep 08 14:35:40 * neverpanic still doesn't understand how OVERRIDES .= ":foo-dev"; SUMMARY_foo-dev ?= "${SUMMARY} - text"; d.getVar("SUMMARY", True) works in packages_rpm.bbclass Sep 08 14:35:59 zeenix: gnome-common? Sep 08 14:36:16 I'd welcome any insight into Yocto's override handling; I've looked into the code, but I don't understand how overrides (aka the cookie monster, apparently) work Sep 08 14:37:06 rburton1, it does that? Sep 08 14:37:27 zeenix: it used to Sep 08 14:39:02 zeenix: fairly simple to figure out where it comes from by grepping the build directory of the recipe to see what variable introduces it Sep 08 14:45:47 neverpanic: did you read the docs? Sep 08 14:46:33 neverpanic: http://www.yoctoproject.org/docs/2.1/bitbake-user-manual/bitbake-user-manual.html#conditional-syntax-overrides Sep 08 14:49:21 joshuagl: I'm familiar with that, yes; unfortunately it doesn't help me to understand whether an override can reference the non-override version of a variable Sep 08 15:04:53 rburton1: so my step 1 passed. I was able to build this massive cmake project for the host again. Sep 08 15:05:05 i've laid out my entire recipe and the results here Sep 08 15:05:13 https://gist.github.com/netskink/8f94dc200dd5f9991dbb4890d94b8113 Sep 08 15:07:13 im trying to build the sdk now, I am pretty sure these tools are not going to be in the sdk. but what do you think? Sep 08 15:09:10 davis: "inherit native" and "BBCLASSEXTEND = native" are somewhat mutually exclusive Sep 08 15:09:26 While you notice that it doesn't immediately crash, it will probably only ever give you host builds Sep 08 15:11:17 I think BBCLASSEXTEND = "native" and not inheriting it explicitly is closer to what you'd need Sep 08 15:15:02 neverpanic: ok Sep 08 15:15:12 when this sdk build completes. i'll remove that. Sep 08 15:18:26 ahh, neverpanic I did try that before. I'm pretty sure if I do this: Sep 08 15:18:34 inherit native Sep 08 15:18:45 BBCLASSEXTEND="native" Sep 08 15:18:51 err, Sep 08 15:18:55 inherit cmake Sep 08 15:18:58 BBCLASSEXTEND="native" Sep 08 15:19:06 then it will fail Sep 08 15:19:45 well, that's the right thing to do. failing or not, manually inheriting native and using bbclassextend will not do what you want Sep 08 15:19:49 it will try to build the code for the target. it will build in the corei7-64-oe-linux and then when it tries to run the exe to build the lfotool and gnerators Sep 08 15:20:02 it will not run since its geared for running on the target. Sep 08 15:20:18 sigh, i'm so confused. Sep 08 15:20:22 so patch its buildsystem to run the binaries from pcmx-native and add that as a dep Sep 08 15:20:31 obviously you can't run the binaries you're building when crosscompiling Sep 08 15:20:58 i am terrible at describing what I'm trying to do Sep 08 15:21:34 my step 1 and step 2 above are still the right thing to do Sep 08 15:21:47 one detail is that the recipe should be foo_version.bb and use BBCLASSEXTEND=native, not inherit native Sep 08 15:22:33 im trying to listen to you folks, truly. Sep 08 15:22:51 but i feel like i have not explained it well. Sep 08 15:23:40 this code which is huge, has this complication where it needs to build some code, run this code to generate additional code, then build the final executables from the generated code. Sep 08 15:23:56 Your problem still seems to be that you need to tell your CMake buildsystem to run the generators from the sysroot of ptmx-native, not the ones it just built Sep 08 15:24:11 davis: from your pastebin step 1 works, you just need to patch the target build so that it doesn't try to build the tools but will use the ones in the sysroot Sep 08 15:24:13 that sounds spot on. Sep 08 15:24:26 rburton1: yes. Sep 08 15:24:27 It might be easier for you to split the generators and the target stuff into separate projects, that would immediately make it clear. Sep 08 15:25:12 trust me, this collection of cmake files is terribly ugly and filled with macros. i dont want to touch it more than I have now. Sep 08 15:25:42 i had to add dependencies in the macros and turn off multicore builds and it finally builds. Sep 08 15:25:57 so the important thing is to get whoever wrote them to understand that this isn't a problem they can ignore and they should support cross builds Sep 08 15:26:11 (ie they fix the cmake lists) Sep 08 15:26:18 It sounds to me like your biggest problem is the terribly ugly CMake stuff, and you might be better off fixing that than trying to work around it in bitbake Sep 08 15:26:28 sigh, the guy who wrote these are no longer here. hence why i'm here. Sep 08 15:26:45 personally i'd rip it all out and replace it with autotools ;) Sep 08 15:27:04 yes, but its not an option. Sep 08 15:27:50 i honestly think someone thought this will be easy but has created such a mess, now its hard to fix. dependecny problems, installs as part of make, generators, etc. Sep 08 15:28:33 but anyway, enough whining. I know that if set what is in the pastebin it does build. Sep 08 15:32:36 But it builds for the host architecture, unless you remove "inherit native", at which point it probably will no longer build. Sep 08 15:33:31 neverpanic: i'm trying to see what happens when this sdk build completes or fails Sep 08 15:34:37 well that was kind of quik. it failed. Sep 08 15:39:19 can i tell an automake based recipe to not use a seperate build directory? Sep 08 15:41:50 fragfutter: inherit autotools-brokensep instead Sep 08 15:42:16 brokensep because the proper resolution is to fix the upstream makefile Sep 08 15:42:36 rburton1: :) thanks. Sep 08 15:51:20 runfetchcmd really sucks in a number of ways Sep 08 15:51:40 can't handle a cmd that's a list, can't retrieve stderr unless the command fails (problematic since stderr isn't just for errors, but anything out of band), etc Sep 08 15:52:52 kergoth: fetch3! Sep 08 15:52:58 ugh Sep 08 15:53:57 runfetchcmd should really have just been a light wrapper around subprocess / bb.process which adjusts env per the fetch env var list and raises fetcherror, anything else is unnecessary Sep 08 18:42:41 joeythesaint: just saw your email now regarding samba, I haven't looked but suspect it is possible to do an arch specific blacklist, if I put together a patch would you consider applying it? Sep 08 18:49:23 marka: If it's justified, sure, but the pam auto-detection / packaging error thing doesn't seem like it should be that hard to fix, and that's across the board, AFAICT. Sep 08 18:50:11 If it were just binutils and it were limited to 32-bit arm, I'm happy to blacklist it for one arch. Sep 08 18:50:53 alright, I will try to take a closer look at it Sep 08 19:58:04 anybody know how I can figure out how to specify the ethernet phy in the kernel dtb? If I dont have anything in there it detects the phy just fine, but if I add a phy-handle and corresponding section in the dtb then it doesnt detect or do anything Sep 08 21:16:11 Is haveing '@' in the path to COREBASE still totally broken? I'm trying to build in jenkins, and it uses '@' in it's workspace paths Sep 08 21:19:01 I'd be surprised, plenty of OE/YP users are using jenkins Sep 08 21:53:04 what is the simple way to add something which is built native to the sdk? Sep 08 21:53:27 ie. just has inherit native. no bbclassextend mods Sep 08 21:55:34 davis: if the recipe has 'inherit native', then it's a native-only recipe Sep 08 21:56:01 that might be a mistake by the recipe author though, if there's nothing else that limits the recipe to being native-only Sep 08 21:56:23 yah, i'm writing it. Sep 08 21:56:42 if you want the recipe to provide a target and an sdk version too, then do BBCLASSEXTEND = "native nativesdk" instead Sep 08 21:56:51 i'm doing some experiments based on reading, but these books dont say anything about nativesdk Sep 08 21:57:02 the recipe must be "generic" enough for that to work, but if you're lucky, it might already be Sep 08 21:57:12 BBCLASSEXTEND showed up in one of the books and it was a java example. Sep 08 21:57:42 ok many thanks Sep 08 21:57:50 the latest version of the reference manual has some more information on BBCLASSEXTEND compared to earlier versions btw: http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#var-BBCLASSEXTEND Sep 08 21:59:37 thank hyou Sep 08 22:00:28 np Sep 08 22:01:25 if you add BBCLASSEXTEND = "native nativesdk" to a recipe foo.bb for example, you'll get the foo, foo-native, and nativesdk-foo "recipes", all from the same bb file Sep 08 22:01:31 -the Sep 08 22:01:37 +the Sep 08 22:04:10 you still need the inherit native, right Sep 08 22:04:32 my understanding is that inherit is for using a class. ie. foo.class Sep 08 22:04:52 and that BBCLASSEXTEND is just that. it extends a class. Sep 08 22:04:58 nope, you shouldn't inherit native if you're using BBCLASSEXTEND Sep 08 22:05:11 so that you can built multiple targets with the same recipe. Sep 08 22:05:21 ok Sep 08 22:05:32 this jives with what kergoth told me earlier today Sep 08 22:05:35 conceptually, it'll generate a separate version of the recipe for each class in BBCLASSEXTEND, where each version inherits that particular class Sep 08 22:05:45 ok, one other thing I read regarding BBCLASSEXTEND Sep 08 22:05:52 this is from the strief book Sep 08 22:06:33 he said, ~if you use BBCLASSEXTEND it builds the target first and then the class(variant?) Sep 08 22:06:36 it also does some rewriting of variables for you though, that usually do The Right Thing, e.g. turning a DEPENDS on foo into a dependency on foo-nativesdk for the nativesdk version Sep 08 22:07:21 davis: dunno what order things will be processed in. it shouldn't usually matter though. Sep 08 22:07:32 but you make a good point Sep 08 22:07:46 if you use a depends, you could force the order Sep 08 22:07:49 maybe Sep 08 22:08:16 davis: think of it as a copy-paste of the recipe with inherits for each of the classes you list + some magic for dependencies and the like that usually do The Right Thing :) Sep 08 22:08:53 cool. i'm about to do another try with BBCLASSEXTEND and not inherit. Sep 08 22:08:56 see3 what happens Sep 08 22:12:44 the magic dependency-rewriting stuff is handled inside meta/classes/{native,nativesdk}.bbclass btw. it only triggers when you use BBCLASSEXTEND to inherit them though. Sep 08 22:13:12 and it's not important that you understand it. might be nice to know that it's there at least. Sep 08 22:13:14 now I see what kergoth was trying to tell me. He gave me this line. Sep 08 22:13:17 or maybe i'm just adding too much detail :P Sep 08 22:13:20 DEPENDS_class-target="pcmx-native" Sep 08 22:13:56 i was looking through my notes trying to find how I would write the target variant variable to be dependent on the native build. Sep 08 22:14:13 i was thinking DEPENDS_pcmx-target = ... Sep 08 22:14:28 but it looks like you specify class suffix Sep 08 22:15:07 DEPENDS_class-target = "${PN}-native" might work Sep 08 22:15:20 PN is just the recipe name, to avoid repeating it Sep 08 22:15:43 never seen a recipe depend on a variant of itself like that :S Sep 08 22:16:17 this is a cmake build which generates exes which generate source. nobody sane would do this. Sep 08 22:16:36 maybe you want DEPENDS_append_class-target = "${PN}-native" too. otherwise, you're overwriting any other stuff you're putting in DEPENDS. Sep 08 22:16:48 heh Sep 08 22:16:57 urr, " ${PN}-native" Sep 08 22:17:04 need to add the space yourself when using _append Sep 08 22:17:21 if had to do this, i would a) not use a generator. b)if absolutely necessary I would use an interpeter that could run on host or target . Sep 08 22:18:04 can't fill the enterprise quota without generating some messy code Sep 08 22:18:29 cool. i saved your notes to a log. I'm going to try this simple thing before I stop for the day. Sep 08 22:19:35 hmm. that did not take long. Sep 08 22:19:40 right off the bat it fails. Sep 08 22:19:54 can not install generator Sep 08 22:19:57 not to put too fine a point on it, but didn't we go over these exact things yesterday? Sep 08 22:20:13 generator? Sep 08 22:20:16 lol, pal i've been fighting this for a few weeks Sep 08 22:20:27 sorry to hear that Sep 08 22:20:29 it took me at least two to get the host to build. Sep 08 22:20:33 its ok Sep 08 22:20:43 fwiw, here is what i've got up to now Sep 08 22:20:47 https://gist.github.com/netskink/8f94dc200dd5f9991dbb4890d94b8113 Sep 08 22:22:05 still has both 'inherit native' and 'BBCLASSEXTEND = "native"' Sep 08 22:22:37 step 1 notes alternate Sep 08 22:35:17 Hrm.. strange problem I'm having. I have a new yocto built kernel running on a custom board. If I boot into the yocto built rootfs the board gets an IP address fine and it looks like its working, but its not. If I try to ping or otherwise access the network it doesnt work. Sep 08 22:35:48 When I type "route" it takes about ~20 seconds to return and then only shows me two routes that look OK, but no local route. Sep 08 22:36:19 If I boot up into my old rootfs built with a different tool using the new yocto kernel, it gets an IP and I can reach the outside net just fine, route returns instantly, etc.. Sep 08 22:37:08 Now, the weird thing is that if I then boot the same kernel and the yocto root file system on the devboard I have (only the DTB is different, also has a differny ethernet PHY), it works fine Sep 08 22:44:20 use rounte -n does it return immediately? if so, it's a name server proble (the 20 seconds bit) Sep 08 22:44:49 the 20 seconds (no name server) may be the result of not being able to access the network... Sep 08 22:50:23 hrm Sep 08 22:50:48 whats weird is that if I try and renew dhcp it returns immediately and even correctly sets the nameservers in resolv.conf Sep 08 22:51:25 route -n does return immediately btw Sep 08 22:52:27 so does anyone build a bare-metal cortex-m4 toolchain/sdk with this stuff? Sep 08 22:52:50 * nerdboy not really bare-metal experienced yet... Sep 08 22:53:23 i made one with crossdev but it's not really made to be "portable" Sep 08 22:54:29 maybe checkout http://launchpad.net/gcc-arm-embedded Sep 08 22:54:41 thats my goto Sep 08 22:57:36 thanks, i've see a little of that Sep 08 22:57:43 *googling Sep 08 22:58:03 but i did want my hardened patches and config Sep 08 22:59:50 i want to replicate something like this => http://pastebin.ubuntu.com/23152279/ Sep 08 23:02:34 i could probably rebuild ubuntu debs Sep 08 23:02:53 prefer something more generic Sep 09 01:48:13 ok i'm sure kergoth, neverpanic and rburton have gone to sleep. Sep 09 01:48:20 but after a few tries i'm almost there. Sep 09 01:48:26 https://gist.github.com/netskink/8f94dc200dd5f9991dbb4890d94b8113 **** ENDING LOGGING AT Fri Sep 09 02:59:58 2016