**** BEGIN LOGGING AT Thu Apr 07 02:59:58 2016 Apr 07 07:26:35 It seems Yocto/raspberry-pi-bsp/rpi-basic-image doesn't produce a finished (partitioned etc.) image as an result but "just" the rootFS (and the boot files etc.). Am I missing something? Apr 07 07:27:55 good morning Apr 07 07:28:27 malinus: it is normal Apr 07 07:29:56 mckoan: Okay, I see. I guess I was tricked by the naming, since it has "image" in it, which made me expect an image. Is this the case for all "image recipes"? Apr 07 07:30:04 Also, good morning to you too. Apr 07 07:34:19 Am I misunderstanding something? Does a compressed file system in one file, and a bunch of boot/dts/config files specify as an "image"? Apr 07 07:40:13 malinus: depends on the MACHINE and its recipes Apr 07 07:43:00 Oh okay. Thanks. Apr 07 13:33:22 hi, I've been trying to follow some examples of kernel modules that are built out of tree with autotools wondered if anyone here had some experience with that? Apr 07 13:33:55 my module builds, however its using the installed system kernel sources rather than the one built for my image Apr 07 13:34:29 I tried running configure `--with-linux=${KERNEL_STAGING_DIR}` per an example I found, however when I use the devshell that's not exported (despite inherting from `module` in my recipe) Apr 07 13:40:09 * tmcguire wonders what the difference between meta-freescale and meta-fsl-arm is, on https://github.com/Freescale/ - both seem to contain the Vivante GPU drivers, for example. Apr 07 13:41:49 neither KERNEL_PATH nor KERNEL_SRC seem to be populated either, which the manual indicates should be the case Apr 07 13:43:22 is it possible that inheriting autotools is clearing those variables out? Apr 07 14:19:28 it it possible to use BB_DANGLINGAPPENDS_WARNONLY inside a specific bb append, to tell local.conf to only consider it for that given append? Apr 07 14:35:45 i.e I don't want all non match appends errors to be ignored, only a specific known one Apr 07 14:49:17 CTtpollard: nope, it's a global setting Apr 07 14:49:37 CTtpollard: but if your'e hittinga n issue where an append is erroring because the layer with the recipe isn't enabled, that's easy to work around Apr 07 14:50:01 we've got an append for linux* Apr 07 14:50:12 with we apply different patches depending on the machine Apr 07 14:50:26 the problem is the wildcard is also hitting the linux headers recipes Apr 07 14:50:31 which we want to avoid Apr 07 14:50:45 without resorting to specific masks in local conf etc Apr 07 14:50:58 linux* isn't a good idea, you'd be better off using specific wildcards for each bsp kernel recipe Apr 07 14:51:19 which gives us another problem Apr 07 14:51:46 we have multiple boards, which meta bsp layer won't always be present Apr 07 14:51:53 https://github.com/MentorEmbedded/meta-mentor/blob/master/meta-mel/conf/layer.conf#L5-L8 Apr 07 14:51:59 at which point bitbake obviously complains it can't find it Apr 07 14:52:05 add that, then put the appends in layer-name specific areas of the repo Apr 07 14:52:12 i.e. https://github.com/MentorEmbedded/meta-mentor/tree/master/meta-mel/fsl-arm Apr 07 14:52:52 then those are only applied when that layer is enabled Apr 07 14:53:02 we've been using board specific dirs, and then only passing them where needed in layers cong Apr 07 14:53:13 but this append should really be global Apr 07 14:55:54 Welp, I'm stuck on this error: http://paste.ubuntu.com/15670964/ , I've previously got a path error, which I thought I fixed, but I have no idea how to handle this one, or what even causes it: http://paste.ubuntu.com/15670964/ Apr 07 14:56:07 accidently pasted it twice, sorry. Apr 07 14:56:57 kergoth: we're managing to only apply the patches if a variable has been set, do you know if it's possible to have two conditionals, using and? Apr 07 14:57:21 it's just python, of course Apr 07 14:57:37 heh that's what I thought Apr 07 14:58:07 so we check if a variable is set to 1, and we also want it check that bpn is == a given value Apr 07 14:58:09 Maybe I should just contact the mainatiner of the particular layer that fails? Apr 07 14:58:12 however it seems to ignore it Apr 07 15:00:22 malinus: that's probably a good idea Apr 07 15:30:11 kergoth: this feels dirty, but could you have linux-${MACHINE}.bbappend? Apr 07 15:32:21 hey so this autotools recipe is installing a number of files I want to include in the `-dev` package to paths like: /usr/src/spl-0.6.5.6/include/sys/fs Apr 07 15:32:57 should I refernce that path completely in the FILES section? it doesn't appear to be the ${libdir}, but I'm not sure what the value of that is Apr 07 15:33:44 for instance adding this to the recipe doesn't seem to work: FILES_${PN}-dev = "${includedir}/linux/sys/*" Apr 07 15:33:55 (excuse me I said libdir above but meant includedir) Apr 07 15:34:17 /usr/src isn't ${includedir} Apr 07 15:35:09 neverpanic: is there a way to identify what ${includedir} is? I assume I just need to tweak the configure line to install there Apr 07 15:35:30 see poky/meta/conf/bitbake.conf for the list of path variables. There doesn't seem to be one for /usr/src, so I guess FILES_${PN}-dev += "${prefix}/src" might be the way to go? Apr 07 15:35:43 bitbake -e recipename contains the values of all variables Apr 07 15:36:01 though I thought the autotools bbclass would handle setting up these variables for me Apr 07 15:36:20 bitbake.conf lists the default path assignments, which are generally not changed Apr 07 15:39:18 hm so /usr/src is likely the srcdir I guess Apr 07 15:44:12 CTtpollard: bbappends are named based on the filename of the recipe. no recipes are named that, even if bitbake expanded filenames, which it doesn't Apr 07 15:47:38 rburton, neverpanic: might either of you be able to point to an example of an out of tree module that also provides additional headers? Apr 07 15:48:04 in order to build the zfs kernel module I need to use spl headers which are artifacts of building the spl kernel module Apr 07 15:48:27 is spl also out of tree? Apr 07 15:48:35 I thought maybe I'd just wrap those up into the `dev` package for spl, but I'm not sure what the "yocto way" is here Apr 07 15:48:38 yes Apr 07 15:48:44 in fact right now I'm only focusing on the spl recipe Apr 07 15:49:09 i guess you'll need custom staging logic to write them to the same place as the kernel headers Apr 07 15:49:13 so the kernel module builds fine, and bitbake complains that a number of files are not packaged (the aforementioned headers) Apr 07 15:49:32 putting them in the -dev will be a good start Apr 07 15:49:51 ok great, but that leads to the next question Apr 07 15:50:10 obviously the paths are incorrect there, so what path transformations need to occur when putting them in the dev package? Apr 07 16:11:40 hi. can somebody point me to an example where perforce is used for fetching sources? Apr 07 16:12:59 purgatory? Apr 07 16:20:58 git-imerge is so awesome for long-lived branches Apr 07 16:21:24 failed dismally last time i tried it, should try it again Apr 07 16:21:34 i've a branch that hasn't been rebased for about six months… Apr 07 16:22:44 rburton: for instance, would it be wise to patch the makefile.am for those installed kernel headers to instead change the install paths to reference like ${STAGING_KERNEL_DIR} or is that begging for trouble Apr 07 16:28:14 rburton: i'm sorry, was that the answer? Apr 07 16:36:30 I'd be surprised if there were any examples of use of the p4 fetcher as I don't think there are any open source projects using p4 Apr 07 16:38:49 joshuagl: thanks :) Apr 07 16:39:33 I guess I'm just not sure how best to get these header files into the staging kernel dir for the subsequent module build, any ideas? Apr 07 16:40:21 alternatively, the configure process for the zfs kmod allows you specify a path to the spl sources Apr 07 16:40:53 so maybe there's an example somewhere of having multiple SRC_URI's in a single recipe, such that I can reference the spl source from within the zfs recipe Apr 07 16:58:48 mbroadst: multiple SRC_URIs are pretty easy; there are probably plenty of examples. Apr 07 16:59:21 you could also install the headers, which will put them into the sysroot, where you can look them up for later builds Apr 07 16:59:22 neverpanic: upon further reflection it seems I need generated objects and headers from the spl build for zfs Apr 07 16:59:38 I'm trying to parse 3 different mailing list threads for the proper staging methods Apr 07 17:00:20 neverpanic: I'm a little confused about installation in this context, iiuc FILES_whatever will install these headers to a package of my choice but not necessarily to the sysroot right? Apr 07 17:00:35 do you mean just adding a post install step to directly call install on the files? Apr 07 17:00:54 the whole contents of ${WORKDIR}/image usually also go into the sysroot Apr 07 17:01:12 and FILES_* matches files from ${WORKDIR}/image Apr 07 17:01:25 so everything that you package will also be part of the sysroot Apr 07 17:02:54 so I was playing around with that. Added all of the files to a test package (with the /usr/share/${PV} prefix intact, nothing changed there) Apr 07 17:03:07 er, /usr/src/${PV} Apr 07 17:03:17 but /usr/src doesn't exist in any of my sysroots Apr 07 17:03:45 But the files were installed by whatever your recipe's do_install() does, right? Apr 07 17:04:28 well do_install is handled automagically by the autotools bbclass, but yes I believe they have been installed (as indicated by the QA warning before I added them to FILES) Apr 07 17:04:55 /usr/src isn't staged to the sysroot, only specific paths are, unless you override that by appending to sysroot_stage_all Apr 07 17:06:30 I see, so indeed the path forward should just to be to create an appended do_install that manually installs those files to the STAGING_KERNEL_DIR Apr 07 17:07:11 (although I see comments from Bruce Ashfield on the ML about not touching that directly, and rather using a custom path for additional headers) Apr 07 17:07:57 yes, you should never touch the sysroot directly in do_install Apr 07 17:08:34 Yes, as soon as your recipe starts using sstate cache those files will be missing otherwise. Apr 07 17:10:03 can either of you think of an existing recipe pair that does something like this then? specifically: one recipe builds a kernel module and provides extra kernel headers, and the second module needs to reference the previous modules objects and headers Apr 07 17:10:49 I just ask for the sake of not bothering you anymore :) Apr 07 17:12:25 * mranostay bothers kergoth Apr 07 17:13:57 personally I'd just put them in their own isolated area in ${D} in do_install and use a sysroot_stage_all_append() to get that into the sysroot, then look there from the other recipe. basically what bruce said Apr 07 17:14:57 grep around for examples. i.e. meta/recipes-core/meta/signing-keys.bb stages /etc/pki into the sysroot, which normally wouldn't be included Apr 07 17:15:20 okay and then in the subsequent recipe just reference a magic path Apr 07 17:16:27 i.e. install to ${D}${includedir}/foobar/, add that in sysroot_stage_all_append, then -I${STAGING_INCDIR}/foobar Apr 07 17:16:55 gotcha, thanks to you both I really appreciate the advice Apr 07 17:17:03 or, if it only adds extra files and doesn't conflict with anything else, just install them to standard locations and they'd be found by default Apr 07 17:17:31 well for whatever reason in its Makefile its installing it to /usr/src/${PN}/include Apr 07 17:18:03 afaict the makefile.am is using like ${top_src_dir}, so that could probably be patched Apr 07 17:18:05 that's one of the common places where kernel headers would go, yes Apr 07 17:18:22 it is? Apr 07 17:18:35 /usr/include/linxu and /usr/include/asm arent' kernel headers anymore, they're the sanitized-for-userland headers used by the c library and installed for use by userland Apr 07 17:19:09 kernel stuff doesn't include those, it needs the headers from the actual kernel source, which is either specified manually, or i.e. follows the symlink from /lib/modules//build/ Apr 07 17:19:17 which in some distros points to a kernel source dir in /usr/src Apr 07 17:19:39 arg sorry Apr 07 17:19:59 kergoth: so, this recipe in particular is installing to e.g. /usr/src/spl-0.6.5.6/include/sys/* Apr 07 17:20:14 that's expected? Apr 07 17:20:42 ah, no, that doesn't seem standard, but there really is no standard for injecting extra kernel headers, so.. Apr 07 17:21:37 right, so what I was originally doing was just adding those to the dev package, but they aren't available Apr 07 17:21:41 regardless, pick a path, or let it use the one it's already using, append to sysroot_stage_all to get that non-standard path staged, then point to that path from the other recipe. what that path is probably doesn't matter Apr 07 17:21:51 * kergoth nods Apr 07 17:21:51 so I guess I'll try that sysroot_stage_all_append Apr 07 17:22:18 both ssysroot population and packaging use the files from $D} from do_install, but they use two different mechanisms and functions to do so Apr 07 17:23:05 i expect you can just copy the bits from meta/recipes-core/meta/signing-keys.bb and change ${sysconfdir}/pki to ${prefix}/src Apr 07 17:23:27 but the fact that it's including the version in the /usr/src path would be problematic since you won't know the version from teh other recipe, so you might also want to change that path Apr 07 17:23:30 move it in do_install Apr 07 17:38:04 kergoth: well conveniently the two modules come in synced releases Apr 07 17:38:29 ah, that makes it easier Apr 07 17:38:40 so ${PV} should be all thats needed, but I think maybe bruce in those emails was just saying make a parallel tree, like /usr-blah/src/include Apr 07 17:39:12 I could just patch the Makefile.am for those headers to use `/usr-blah/src` instead of `${top_src_dir}` I guess Apr 07 18:25:30 RP: if you're around, could use another set of eyes on something real quick. very short diffs. https://github.com/kergoth/poky/commit/14d521b vs https://github.com/kergoth/poky/commit/d24c6d5 Apr 07 18:26:07 or anyone else, really Apr 07 18:47:11 I dislike how implicit the latter implementation is, but getting all the layer maintainers to modify their layer.conf seems like a losing proposition, so I'm inclined to say we should go with the latter Apr 07 19:18:25 How can I force BitBake data smart to be updated? Apr 07 19:26:55 kergoth: now I'm reading this, thinking I should just do a do_install_append and install everything directly to $STAGING_KERNEL_DIR: https://github.com/openembedded/openembedded-core/blob/master/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc#L5 Apr 07 19:29:08 and it looks like this is doing something close to what I want maybe: https://github.com/open-switch/ops-build/blob/master/yocto/poky/meta/recipes-kernel/cryptodev/cryptodev-linux_1.7.bb Apr 07 19:29:49 linux-libc-headers is special, you should not use it as a basis of anything. it installs files specifically for use by the C library, not kernel stuff Apr 07 19:30:44 yeah, I see that in the note, but the note continues to mention that if you want to install a kernel header you should just directly install to the staging dir Apr 07 19:31:13 the second recipe I just posted seems to be the latter of your suggestions above, just install the files directly to ${D} and hope they don't clobber anything Apr 07 19:37:57 oh but thats for eventual use in the image, not to build another recipe Apr 07 19:53:21 kergoth: hmm, that is a really tricky one. I do prefer the former, the latter does seem a bit too magic :/ Apr 07 19:55:36 kergoth: Since we'll have to live with this for a long time, which would we ideally prefer? I'd then suggest we go with that... Apr 07 19:56:21 Yeah, I prefer the former as well. but for a layer to support both older and newer bitbakes they'd need LAYERDIR_RE ?= "${LAYERDIR}" too :\ Apr 07 19:56:45 * kergoth shrugs Apr 07 19:58:45 kergoth: still tempted by the former... Apr 07 19:58:59 kergoth: I've been burnt by too many nasty things we've had to live with Apr 07 19:59:18 Yeah, I hear you. magic tends to break, or at the best we end up stuck maintaining it indefinitely Apr 07 19:59:40 K, the former it is, I'll submit it for 2.2 Apr 07 20:12:38 kergoth: rad, got it working :) thanks for the guidance Apr 07 20:12:43 np Apr 07 20:15:06 kergoth: sounds good thanks Apr 07 20:15:21 np, thanks for the help/input Apr 07 20:24:41 kergoth: maybe I'm misunderstanding things, but couldn't layers that want to support older and newer bitbake versions do LAYERDIR_RE ?= "${@re.escape(d.getVar('LAYER', True))}"? Apr 07 20:28:46 neverpanic: nope, re isn't imported Apr 07 20:28:54 you'd ahve to split off a .inc, create a def'd function, and import re Apr 07 20:29:06 that's why it had to be implemented in bitbake rather than just doing it in the metadsata in the first place Apr 07 20:32:34 kergoth: ${@__import__('re').escape(d.getVar('LAYER', True))} Apr 08 02:47:40 is there a recipe for eclipse app? **** ENDING LOGGING AT Fri Apr 08 02:59:58 2016