**** BEGIN LOGGING AT Fri Oct 02 02:59:59 2015 Oct 02 06:55:15 good morning Oct 02 07:23:31 morning all Oct 02 07:27:24 hi bluelightning Oct 02 09:19:15 morning Oct 02 09:20:59 bluelightning: when you do inherit native in a recipe, is the install procedure different? why is ${prefix} set to an absolute path? this causes a tree of absolute paths inside my ${D}. It seem to "work", cause somehow do_populate_sysroot-handles it, but I'm confused. Do native recipes not need a FILES_${PN}? Oct 02 09:22:03 native recipes don't use packaging Oct 02 09:22:14 I forget why they have the full path under ${D} but it is expected Oct 02 09:22:26 i.e. the full path as ${prefix} Oct 02 09:31:45 bluelightning: i see. Is it possible to list all files installed into sysroot by a certain recipe? Oct 02 09:32:21 mago_: yes, there are manifest files written into tmp/sstate-control listing all files staged by each sstate task Oct 02 09:34:24 bluelightning: ok. what controls what gets deployed into sysroot by populate_sysroot? cause i got 2 native recipes that both populate their ${D} as expected, but only one of them gets their files populated into sysroot. I see a manifest for the other recipe, but it only lists 1 file and thats the "sysroot-providers/recipe-name" file Oct 02 09:36:24 mago_: what path under ${D} are they placing their files in? Oct 02 09:36:32 well, the one that's not working Oct 02 09:37:32 bluelightning: well, it's the absolute path (of course), and then it's usr/node_modules/... Oct 02 09:37:39 (it's a NPM module) Oct 02 09:39:03 bluelightning: so basically,.. ${D}/home/mago/../path/to/x86-sysroot/usr/node_modules/... Oct 02 09:40:03 I suspect the issue is that /usr/node_modules isn't one of the paths that is staged by default Oct 02 09:40:20 we only stage a subset of what is installed to ${D} Oct 02 09:40:36 why doesn't native recipes rely on FILES_${PN} ? Oct 02 09:40:58 * Crofton|work hopes the monsoon doesn't delay his flight Oct 02 09:41:17 because there is no packaging of any kind for native recipes... also staging to the sysroot is not connected to packaging Oct 02 09:41:50 yeah, but selecting which files to be staged is kind of like selecting which files to package? Oct 02 09:43:26 bluelightning: anyway, can i change which files to stage? Oct 02 09:45:20 bluelightning: also, here's a weird observation: if i compile my NPM module in such way that it also includes a binary (e.g puts a /usr/bin/asdf into ${D}/${prefix}, THEN it seem to stage all files (including my /usr/node_modules). So it's very unclear to me how the staging filter changes based on what files are actually in ${D} Oct 02 09:45:25 mago_: see the last four lines of meta/recipes-graphics/xorg-font/font-util_1.3.1.bb Oct 02 09:45:52 mago_: that I don't have an explanation for right now I'm afraid Oct 02 09:46:16 the logic is all in sysroot_stage_dirs() in meta/classes/staging.bbclass though Oct 02 09:50:04 bluelightning: thanks, the sysroot preprocess seem to work Oct 02 10:02:49 otavio, JaMa is it possible to compile meta-qt5 with bluez5? I mean qtconecctivity? Oct 02 10:13:13 does anybody know? Oct 02 13:02:39 anyone have experience with building npm packages with OE? i see an issue with npm downloading and installing its dependencies on its own, since that will circumvent the bitbake fetcher (bypassing download mirrors, sstate cache and everything). I can no longer rebuild my tree without internet access Oct 02 13:05:29 mago_: that is unfortunately how it behaves :/ Oct 02 13:05:47 I don't know if anyone has conclusively beaten it into submission Oct 02 13:08:18 yes, but for cost of hardcoding a lot of configuration Oct 02 13:09:03 https://github.com/openwebos/meta-webos/tree/master/recipes-upstreamable/node-gyp Oct 02 13:09:09 i noticed there is something called "shrinkwrap" that somehow can calculate the entire dependency tree and provide URIs for them. Perhaps bitbake could tap into that Oct 02 13:10:02 there's also https://github.com/imyller/bitbake-npm which adds a npm:// to bitbake, but it doesn't seem to account for recursive dependencies Oct 02 16:50:42 join #synology **** ENDING LOGGING AT Sat Oct 03 02:59:58 2015