**** BEGIN LOGGING AT Wed Nov 08 03:00:02 2017 Nov 08 10:37:08 hi bluelightning , in case you haven't seen that: https://www.linkedin.com/pulse/possible-issues-yocto-devtool-modify-utility-nikolay-merinov/. yeah.. i am surprised too , to share a linkedin link here ;) Nov 08 10:37:37 that came from https://www.linkedin.com/groups/3636272/3636272-6331237321429565444 Nov 08 10:38:21 ndec: thanks, very interesting Nov 08 10:38:38 yes, i think so.. Nov 08 10:41:13 hopefully I can address all of those Nov 08 10:41:32 at the least, reproduce and file bugs Nov 08 10:47:56 bluelightning: cool. he has brought valid concerns.. which are exactly the same you and I discussed a long time ago! Nov 08 10:50:20 ndec: hmm, my apologies, I don't recall discussing these particular issues Nov 08 10:52:55 bluelightning: well not the devtool issues, but the issues of using OE/YP from a developer's perspective Nov 08 10:53:32 right Nov 08 10:53:39 ah, I have to sign up for the second link Nov 08 10:54:58 right, that's a link to a discussion intside the YP group on linkedin. Nov 08 11:16:05 i'd like to setup a initramfs, how does that integrate with OE? i suppose i can just build the initramfs as any other image and then ensure its get loaded by uboot instead of my normal rootfs, and then have the initramfs mount the normal rootfs and finally switch_root. However, this will be a quite big change to our current system (perhaps the partition table has to be changed so a new initramfs partition is Nov 08 11:16:07 added), so if possible i'd like to instead bundle the initramfs with the kernel. Does OE support building a kernel with an embedded initramfs that is also built by OE? essentially, the kernel recipe would depend on the initramfs image recipe ? Nov 08 11:20:29 mago1: well there should be core-image-minimal-initramfs as an example to get you started Nov 08 12:05:12 LetoThe2nd: do you know of any examples that isn't x86? Nov 08 12:20:02 mago1: why should core-image-minimal-initramfs be x86 only? Nov 08 12:20:41 LetoThe2nd: it seem to be limited to x86 in its COMPATIBLE_HOST, since it uses GRUB and EFI Nov 08 12:22:31 mago1: ah interesting, didn't notice that. Nov 08 12:22:48 i'm sure that can be ripped out if you don't need the bootloader/liveimage magic Nov 08 12:23:10 but then there's probably no readymade image Nov 08 12:24:24 but yeah, i get the idea. there's an image, and it has customized init that does stuff before it switches root. my question was more like: can i embed a initramfs with the kernel when using OE? i know i can compile the kernel in a way that it piggy-backs a initramfs onto its binary and automatically mount that when the kernel runs. now if i'd like to build that kernel and the embedded initramfs from OE, how would Nov 08 12:24:26 i express it in terms of recipes and dependencies? Nov 08 12:40:25 mago1: create an image.bb, then use the bundle variables to push it into the kernel - https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#building-an-initramfs-image Nov 08 12:43:02 nrossi: thank you, INITRAMFS_IMAGE_BUNDLE is exactly what I was looking for Nov 08 13:20:27 I'm looking for a way to change the version file content Nov 08 13:29:08 in the rootfs Nov 08 14:42:05 is the nodejs in meta-oe the "canonical" nodejs? Nov 08 14:47:18 lol: http://layers.openembedded.org/layerindex/branch/master/recipes/?q=nodejs Nov 08 14:48:09 hmm, why is the layer index greying out most of the hits? Nov 08 14:48:12 new feature? Nov 08 14:54:07 yeah that's why i asked ;) Nov 08 14:54:25 i think we should push the node bits out of core and move them alongside nodejs Nov 08 14:54:29 (npm.bbclass for example) Nov 08 15:15:30 armpit: Not in yet, I assume Nov 08 15:17:35 Tartarus, you mean awake ? Nov 08 15:17:42 armpit: Well, awake and working Nov 08 15:18:10 I am playing. working in 45 minutes Nov 08 15:18:34 OK, when you're up for talking about some pyro/morty backports, let me know please Nov 08 15:18:44 that is play Nov 08 15:18:48 ha Nov 08 15:19:25 Tartarus, talk away Nov 08 15:19:26 In oe-core, f4edc200d3a9645f9674eae0f8d10926680ba4f8, 05f6ff9a500bb97d8ef1f943eff1b9d90246651f and 2e0044ed32485fe24e0cedd9354dd546cb9c47a5 are needed to make dpkg useful Nov 08 15:19:46 They hit master, but not pyro (bah!) nor morty (OK, expected that) Nov 08 15:20:01 If you're OK with them for both, that would save me some headache, but I can deal otherwise Nov 08 15:20:40 * armpit looks.. gotta do Rocko first Nov 08 15:21:20 They are in rocko Nov 08 15:21:39 k Nov 08 15:30:49 Tartarus, pulled them in to oe-core-contrib stable/pyro-next Nov 08 15:31:04 armpit: Thanks. Nov 08 15:31:10 Not critical enough for morty too? Nov 08 16:05:47 morty is tricky as I have already sent a pull request and if I pull those in , it may be in before pyro Nov 08 17:08:23 OK, thanks Nov 08 17:08:37 * Tartarus next runs into something not yet fixed in master, sighs, prepares patch Nov 08 17:13:12 * Tartarus bangs head into wall, walks away Nov 08 19:19:39 JaMa, pull request sent for your github Nov 08 19:20:42 armpit: so you want to control only meta-oe layers? How will you update to newer oe-core? Nov 08 19:22:48 ah, ok. so are you ok to me to drop those other two repos? qt5 and browser ? Nov 08 19:26:26 armpit: https://github.com/shr-project/jenkins-jobs/commit/83894f4d4e51939e21a3342b4c7a4f3aa378ad41 Nov 08 19:27:27 https://github.com/shr-distribution/shr-makefile/tree/akuster/master-all Nov 08 19:27:40 sweet.. thanks Nov 08 19:28:03 armpit: if you don't want to test meta-browser and meta-qt5 then it would make your builds much faster Nov 08 19:28:42 but more difficult for people to notice when new issues are introduced there Nov 08 19:29:06 correct. I plan on leaving them in Nov 08 19:32:38 armpit: old build is finished, I've just sent the report and updated wiki pages (created new one for sumo) Nov 08 19:32:39 JaMa, ok for me to trigger a build? Nov 08 19:32:47 k Nov 08 19:32:47 so if you want, then go ahead with next build Nov 08 19:33:03 k Nov 08 19:33:18 * armpit looks at notes Nov 08 19:35:40 JaMa, triggers builds Nov 08 19:35:48 thanks Nov 08 19:53:39 == Tested changes (not included in master yet) - meta-openembedded == Nov 08 19:53:40 fatal: ambiguous argument 'up/master..stagging/master-next': unknown revision or path not in the working tree. Nov 08 19:53:45 hmm something is wrong Nov 08 19:55:03 will restart the builds after _workspace_prepare to switch into different shr-makefile branch Nov 08 20:01:29 hopefully fixed now Nov 08 20:36:12 k Nov 08 20:51:53 how can I add a direcotry to check for conf files in via something like local.conf? Nov 08 20:53:29 Crofton|work: you mean include all conf files in a specific directory? Nov 08 20:53:53 sure Nov 08 20:54:18 I hae a container, and want to create a way to insert a site.conf from outside the caontainer Nov 08 21:00:57 off-site.conf ; ) Nov 08 21:26:02 Crofton|work: not local.conf, but you can adjust BBPATH in bblayers.conf. Nov 08 21:26:20 yeah Nov 08 21:26:28 I tihnk I am thinking that way Nov 08 21:27:11 ort of like rburton meta-ross to insert site.conf Nov 08 21:37:50 hmm, SO BBPATH = "${TOPDIR}:/home/build" Nov 08 21:38:12 means /home/build/conf/site.conf would get picked up Nov 08 21:40:36 yep Nov 08 21:40:52 i used to use that same mechanism to load my site.conf from ~/.oe, back in the day **** ENDING LOGGING AT Thu Nov 09 03:00:01 2017