**** BEGIN LOGGING AT Sat Oct 17 02:59:58 2015 Oct 17 03:47:51 hi all, I want to use the runqemu command on a built image, but I want to start the VM with two vNICs instead of the default one. Is that possible? Oct 17 04:19:46 you can specify any custom arguments to be passed to qemu with qemuparams="..." Oct 17 04:19:51 see the qemu documentation for what to pass it Oct 17 11:09:43 hey. just hit an build error with http://paste.ubuntu.com/12816775/ <- eglibc/eglibc_2.19.bb and this issue: | Makefile:91: *** OPTION_EGLIBC_NSSWITCH_FIXED_CONFIG variable left unset. Stop. Oct 17 11:10:00 anyone an idea how to fix that? i'm on daisy Oct 17 17:03:15 is there some consistency to what bar refers to in FOO_bar, or is it all ad-hoc? Oct 17 19:09:14 frobar: Not sure what you mean by that. FOO_bar is a variable name. If bar is listed in OVERRIDES, then it's seen as an override, so the value of that variable would overwrite FOO. If not, it'd be left as is. Oct 17 19:35:04 kergoth: i mean in the sense that the _bar part sometimes seems to be a machine, sometimes an architecture, sometimes a recipe name, sometimes something else... Oct 17 19:35:14 read meta/conf/bitbake.conf Oct 17 19:35:15 depending on the particular variable Oct 17 19:35:18 the value of the OVERRIDES variable Oct 17 19:35:30 it's not inconsistent, again, it's the values in overrides Oct 17 19:37:18 OVERRIDES is conceptually a layering mechanism of specificity which also supports our orthogonal distro, machine, and image axes. It allows the distro to exert its preferences in the metadata, and allows more specific knowledge of the target to be used in preference to less specific knowledge of the target. _ is used in preferences to _ which is used in preference to the base value, for example, because that knowledge is more specific, Oct 17 19:37:19 and more likely to be accurate. Oct 17 19:37:35 if you look at the include files pulled in by bitbake.conf, it's basically the same things overrides has Oct 17 19:39:27 the order of elements in overrides reflects the specificity i mentioned. forcevariable will override anything else, to let the user override anything set anywhere in the metadata if they want to Oct 17 19:39:46 the yocto project documentation covers overrides as well, i believe Oct 17 19:40:17 so when bitbake sees something like "FOO_bar = ...", it checks if "bar" appears in OVERRIDES, and does the assignment if so? Oct 17 19:40:21 to make it a bit more concrete :P Oct 17 19:40:32 no, FOO_bar is a valid variable in its own right Oct 17 19:40:40 if bar is in overrides, then FOO_bar replaces FOO Oct 17 19:40:43 otherwise it'd be left as is Oct 17 19:41:03 the bitbake manual covers this as well Oct 17 19:42:08 does FOO_bar = "baz" do something like FOO_bar = "baz"; if "bar" is in OVERRIDES: FOO = "baz";? Oct 17 19:42:35 or FOO = FOO_bar... Oct 17 19:48:12 yes, FOO would be "baz" in that case Oct 17 19:48:29 replacing any existing value with FOO_bar's value Oct 17 19:48:44 it's really just a way of defining values conditionally Oct 17 19:48:53 we don't have if statements in our file format, but we have this Oct 17 19:49:46 yeah, i got the point. just didn't know the underlying mechanism. looks like OVERRIDES is it then, and that you can specify different types of things after _. Oct 17 19:51:06 the thing is, the override separator (_) is also valid in variable names. just because you used an _ doesn't mean it'll do anything, unless the right side of it is listed in OVERRIDES :) Oct 17 19:51:29 foo_bar_baz could just be the name of a variable, no conditionals involved at all Oct 17 19:51:58 yeah, that makes sense Oct 17 19:53:23 second confusion: is S meant as a way for the user (recipe writer) to tell yocto where stuff ends up after it is unpacked? Oct 17 19:53:37 with the "base" directory for unpacking always being WORKDIR Oct 17 19:53:56 i found it weird that recipes would assign to S at first, but if that's it, then it kinda makes sense... Oct 17 20:00:22 yep, that's exactly what it is, we don't examine the tarball contents, so we need to know where it ends up Oct 17 20:00:50 in hindsight, we should have had code to be able to strip off the leading directory from the tarball contents, and just put that into S rather than having to tell it where the tarball wants it Oct 17 20:02:51 i interpreted S as an output variable at first. then it got real confusing. :) Oct 17 20:03:00 output to the recipe writer that is Oct 17 20:04:26 * kergoth nods, no, it's describing the input Oct 17 20:08:29 where do the default do_* functions come from? are they built into bitbake, or is there some inheritance thing going on? Oct 17 20:09:21 everything is defined in the metadata Oct 17 20:09:46 not much is implicit. bitbake parses bblayers.conf and layer.conf from each layer in BBLAYERS, then it parses bitbake.conf, then it parses base.bbclass and every other bbclass listed in the INHERIT variable Oct 17 20:09:56 base.bbclass defines most of the base functions Oct 17 20:10:27 ok Oct 17 20:11:43 there's a good writeup on the basics of how bitbake works in a book that elizabeth flanigan wrote up that you might find interesting, covers some of the high level concepts and history - http://www.aosabook.org/en/yocto.html Oct 17 20:12:33 i like working "bottom-up" at least. i find it hard to understand high-level stuff if i don't understand the implementation. Oct 17 20:12:44 fair enough Oct 17 21:14:02 if D is ${WORKDIR}/image, then it seems it would be unique per package. does that mean that every package that puts things into e.g. /usr/bin needs to create those directories? Oct 17 21:14:23 and how are all the different Ds then merged to create the rootfs? Oct 17 21:14:50 seems it'd get messy as directory permissions could differ for different /usr's for example :/ **** ENDING LOGGING AT Sun Oct 18 02:59:58 2015