**** BEGIN LOGGING AT Mon Apr 04 02:59:58 2016 Apr 04 07:31:25 good morning Apr 04 14:28:55 JaMa, Did you had this problem with qtquick1 ? Project ERROR: Unknown module(s) in QT: script-private Apr 04 14:58:20 caiortp: no Apr 04 14:58:29 ok Apr 04 15:14:34 otavio: any further comment, after cleaning the spurious crap out of the PR for FF path cleanups? Apr 04 16:46:10 WarheadsSE: I merged it Apr 04 16:50:43 oh sweet, didn't get the notification. Apr 04 18:31:36 Hmm, wonder if bitbake-layers add-layer should accept multiple layers, or if we should have an add-layers Apr 04 18:31:49 or perhaps both. let add-alyer accept multiple, and alias add-layers to add-layer Apr 04 19:17:16 RP: I sent a regression fix for the oe-buildenv-internal script. It broke our company tools for no good reason, in last refactoring. Apr 04 21:25:25 If I am using the jethro release of oe-core and meta-intel, which release of bitbake do I use? Does it matter? Apr 04 21:27:30 it does matter, yes. I don't know the version off the top of my head, i expect you could read the jethro release notes, or check what bitbake version is on the jethro branch of poky (which is an integration of bitbake, oe-core, meta-poky (now meta-yocto) and meta-yocto-bsp) Apr 04 21:28:00 https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/bitbake/lib/bb/__init__.py?h=jethro#n24 Apr 04 21:28:11 shows 1.28 Apr 04 21:32:35 kergoth: thanks! Apr 04 21:32:41 np Apr 04 22:01:41 If I choose not to use yocto, can I just copy the "scripts" directory and and oe-init-build-env into my "source" directory? Apr 04 22:01:58 from Poky that is Apr 04 22:02:00 Or is there a better way of doing this? Apr 04 22:14:02 riz__: that really doesn't make a great deal of sense. Apr 04 22:14:07 scripts and oe-init-build-env are part of oe-core Apr 04 22:14:25 poky just integrates it with the other components i mentioned Apr 04 22:14:36 you can easily use the pieces on their own, and plenty of us do Apr 04 22:15:14 Ohh. I feel silly Apr 04 22:15:16 I see it Apr 04 22:16:02 That is what I am doing Apr 04 22:16:17 Just trying to piece the different parts together independent of poky Apr 04 22:16:55 I am also trying to create my own bsp layer which is highly dependent on what is in meta-intel. Apr 04 22:16:57 nothing to it. clone oe-core, clone bitbake, . ./oe-core/oe-init-build-env build bitbake Apr 04 22:17:09 Yup. Just did that Apr 04 22:17:12 second arg to oe-init-build-env is the path to bitbake, if bitbake wasn't inside of oe-core Apr 04 22:17:45 Would it be better to just create my own BSP layer and copy what is needed from meta-intel or use mta-intel and just append or add things? Apr 04 22:17:55 What is the best approach? Apr 04 22:18:27 I am trying to make this very customized to my minnowboard with a custom touchscreen Apr 04 22:29:39 i'd create a new bsp layer with a new machine, have your machine.conf include the intel one and then build up from there (require conf/machine/.conf), and set MACHINEOVERRIDES = ":" so overrides in the layers for that mahcine still applpy to yours Apr 04 22:30:04 i've done that many times in the past to make changes to upstream machines for our needs Apr 04 22:30:43 also set LAYERDEPENDS in layer.conf for your bsp layer so tooling knows your layer depends on the intel layer Apr 04 22:38:18 OK. I just figured I could just create an enite new bsp layer that copies a lot of meta-intel. The reason being that I want to strip some of the features from a certain meta-intel machine. Apr 04 22:38:36 That way there isn't too much "layer clutter" Apr 04 22:39:09 But are you not recommending that due to the possiblity of a broken BSP layer? Apr 04 22:39:11 so you'd avoid layer proliferation in favor of making it extremely hard to maintain over thel ong term, since you'll get out of sync with upstrema changes Apr 04 22:39:19 depends on your needs, i suppose Apr 04 22:40:26 I hear ya. Just throwing my thoughts out there. But I'm convinced with what you recommend. Just wanted to secure my decision :) Apr 04 22:40:28 Thanks again Apr 04 22:45:20 np Apr 04 22:45:56 we always have a lot of flexibility. upside is it can always be made to fit your needs, generally, but the downside is figuring out which of the possibilities best meets your needs.. Apr 04 22:51:11 Right Apr 04 22:52:08 My issue was just that I dont need things like wifi and bluetooth, so I have to remove those somehow Apr 04 22:52:22 As opposed to just making a new BSP with just what I want that doesnt depend on anything Apr 04 22:52:35 wifi and bluetooth is a decision made by both the machine and the distro Apr 04 22:52:57 having it in MACHINE_FEATURES controls whether packagegroups are enabled for those tools, but their existance in DISTRO_FEATURES controls whether those packagegroups are installed in images by default Apr 04 22:53:07 it sounds like you may want a custom distro more than a custom machine Apr 04 22:53:19 s/enabled/emitted/ Apr 04 22:53:25 Hmmm. ok Apr 04 22:54:08 https://www.dropbox.com/s/gxb6uxlputaupmj/OpenEmbedded%20-%20Metadata%20Structure%20-%20Distro%2C%20Machine%2C%20Image.txt?dl=0 may be of interest (though certain small things are out of date, it's mostly still accurate) Apr 04 22:55:00 Awesome. I will have a look. Apr 04 22:55:38 I get confused when things are just included as an option and when they are actually installed Apr 04 22:56:01 But I will read on and hopefully get more clarification as I study the different layers **** ENDING LOGGING AT Tue Apr 05 02:59:58 2016