**** BEGIN LOGGING AT Mon Jun 15 02:59:58 2015
Jun 15 06:35:07 <parrot> is there something like yocto kernel mailing list? I'm having issue with perf and I'm thinking to write to yocto's mailing list about this but I'm not sure if there's a more specific mailing list out here
Jun 15 06:57:49 <mckoan> parrot: yes it exists linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo
Jun 15 07:10:05 <mckoan> good morning
Jun 15 07:28:14 <redengin> good morning
Jun 15 07:47:10 <parrot> mckoan: splendid. Thanks
Jun 15 08:18:07 <bluelightning> morning all
Jun 15 09:02:55 <LetoThe2nd> bluelightning: concerning our discussion about externalsrc not picking up files, it was a false positive. $coworker had added some magic i wasn't ware of
Jun 15 09:03:15 <bluelightning> LetoThe2nd: ah ok... well, glad you tracked it down in the end :)
Jun 15 09:03:18 <LetoThe2nd> bluelightning: e.g. no bugreport/action needed, thanks for your input.
Jun 15 09:03:22 <bluelightning> np
Jun 15 11:12:38 <lpapp__> good morning
Jun 15 11:12:47 <lpapp__> what is the way of building both the image and sdk?
Jun 15 11:13:02 <lpapp__> it seems that bitbake -c populate_sdk myimage only created the SDK, not the image.
Jun 15 11:13:19 <lpapp__> and I cannot see a "do_image" thing, perhaps because the image is just a recipe.
Jun 15 11:22:14 <erbo> lpapp__: the default task for an image is do_build
Jun 15 11:23:34 <lpapp__> so perhaps -c populate_sdk build or the problem might be somewhere else as -c populate_sdk is supposed to build the image, too?
Jun 15 11:24:08 <erbo> Do -c accept multiple argument?
Jun 15 11:24:45 <erbo> I don't think populate_sdk is supposed to build the image, but I'm not sure
Jun 15 11:24:50 <LetoThe2nd> lpapp__: the sdk doesn't depend on the image, so it doesn't get built. it only need the things *in* the image, not the image itself
Jun 15 11:24:53 <rburton> no, populate_sdk doesn't build images
Jun 15 11:25:06 <rburton> (what LetoThe2nd said)
Jun 15 11:25:06 <LetoThe2nd> erbo: and no, multiple commands are not supported so far.
Jun 15 11:25:12 <rburton> but you can do this :
Jun 15 11:25:23 <rburton> $ bitbake somerecipe:task somerecipe:task
Jun 15 11:25:47 <rburton> (yes, bitbake needs to shout that it can do that)
Jun 15 11:26:29 <lpapp__> interesting, thanks to all :)
Jun 15 12:34:16 <lpapp> rburton: so would bitbake myimage myimage:populate_sdk work
Jun 15 12:34:30 <rburton> that would generate the image and the sdk at the same time, yes
Jun 15 12:34:38 <rburton> you might need do_, can't remember
Jun 15 12:34:50 <lpapp> ok, let me test that
Jun 15 12:35:27 <bluelightning> there is already a bug open about noting that in bitbake's help output FYI
Jun 15 12:35:36 <bluelightning> assigned to me ;)
Jun 15 12:37:37 <lpapp> thanks. Yes, it needs do_
Jun 15 13:00:56 <rburton> probably worth fixing that tbh
Jun 15 13:35:58 <gourve_l> hi
Jun 15 13:36:14 <gourve_l> how does /etc/environment is generated?
Jun 15 13:48:57 <bluelightning> gourve_l: I can't immediately find any reference to that...
Jun 15 13:49:19 <bluelightning> gourve_l: you may be able to get an answer for your configuration using: oe-pkgdata-util find-path /etc/environment
Jun 15 14:11:27 <gourve_l> thx bluelightning. I didn't find any clue with oe-pkgdata-util
Jun 15 14:11:54 <garghoule> Anyone here has experience with Intel Edison / Mac OS X / Sparkfun Base Block? :)
Jun 15 14:12:06 <gourve_l> maybe I forgot to precise, basically, this file doesn't exist in my rootfs :/
Jun 15 14:16:26 <bluelightning> gourve_l: ah, ok, in that case I'm not surprised that oe-pkgdata-util won't find it...
Jun 15 14:17:13 <garghoule> Anyone? :P
Jun 15 14:17:50 <bluelightning> garghoule: not me... but I suspect you may have a better chance of getting an answer in the Intel Maker forum
Jun 15 14:18:08 <garghoule> kk, some people pointed me to this irc :D
Jun 15 14:18:26 <garghoule> and I really like the back and forth of irc :D
Jun 15 14:18:39 <garghoule> bluelightning: thanks for the pointer, i'll try there too
Jun 15 14:19:33 <bluelightning> I can try to help if it's actually related to the build system, but as for using the board with MacOS that's well outside of my realms of experience (and not really on topic for this channel)
Jun 15 14:21:18 <garghoule> okok
Jun 15 14:21:45 <bluelightning> gourve_l: from googling it kind of looks like /etc/environment isn't used everywhere... it's blank on my Fedora system FWIW
Jun 15 14:22:36 <garghoule> bluelightning: Well.. I have the base block from sparkfun (which is very similar to Intel's mini breakout board, but the console port is also a power port) and I installed the drivers, installed everything from the getting started intel guide
Jun 15 14:23:03 <garghoule> and when I plug both usb in, I get the Edison volume but there isn't another volume that mount.
Jun 15 14:23:18 <garghoule> Trying to figure what is going wrong, but it's out of my realm of experience so far :P
Jun 15 14:23:30 <bluelightning> yeah, that's definitely one for the forums
Jun 15 14:23:35 <garghoule> So I was wondering if its something well known pertaining to the sparkfun base block or mac osx specifically
Jun 15 14:23:39 <garghoule> kk thanks :P
Jun 15 14:23:42 <garghoule> haha :D
Jun 15 14:24:49 <bluelightning> gourve_l: I guess ultimately if nothing on our side is creating it you are free to create it in a recipe you write yourself, but I can't guarantee anything will read it
Jun 15 14:27:24 <kergoth> morning
Jun 15 14:29:46 <garghoule> mor ning!
Jun 15 14:41:03 <gourve_l> bluelightning: I found /etc/profile which might be enough for my needs. I'll try to add my own profile
Jun 15 14:41:18 <bluelightning> morning kergoth
Jun 15 14:41:27 <bluelightning> kergoth: no comments on the tinfoil RFC?
Jun 15 14:46:11 <kergoth> haven't had a chance to look over the code, just got back from a 2 week trip to visit family in minnesota
Jun 15 14:46:16 <kergoth> in general it sounds good
Jun 15 14:49:03 <bluelightning> ok, fair enough
Jun 15 14:49:22 <bluelightning> the bit I'm keen to have feedback on is what the API should look like
Jun 15 14:51:46 <kergoth> k
Jun 15 15:00:54 <bluelightning> Crofton|work: I've asked alejandro to talk to you re scipy
Jun 15 15:01:27 <bluelightning> Crofton|work: I just remembered, at OEDAM we were talking about various people going away and figuring out alternatives for a demo UI - did anything happen with that?
Jun 15 15:02:16 <bluelightning> more of a question for #oe perhaps, feel free to reply there instead if you want :)
Jun 15 15:03:36 <rburton> bluelightning: for conference demos luna would be awesome, but its probably overkill for poky :)
Jun 15 15:04:55 <bluelightning> rburton: the discussion covered all bases: a) having a UI for framework testing purposes, b) having a nice demo UI, c) having something that users could build on
Jun 15 15:07:07 <bluelightning> part of the problem is that we have up to this point been pointing at sato for b and c
Jun 15 15:07:27 <bluelightning> at least as far as some of our documentation goes
Jun 15 15:07:32 <Crofton|work> bluelightning, not to my knowledge
Jun 15 15:07:40 <Crofton|work> Jefro had an action to schedulke a meeting
Jun 15 15:07:46 <bluelightning> Scott's new rewrite of the QS guide should address at least that part
Jun 15 15:08:47 <rburton> i'll be the first to admit that sato certainly sucks for (b) and is only a contenter for some users of (c)
Jun 15 15:09:05 <rburton> (vernier still use a fork of matchbox-* 0.9x for their ui)
Jun 15 15:11:16 <bluelightning> rburton: you're still not in #oe btw ;)
Jun 15 15:13:10 <rburton> #yocto and #oe - it's like the people's front of judea
Jun 15 15:13:26 * Crofton|work aliases #yocto to #oe-intel
Jun 15 15:13:37 <rburton> haha!
Jun 15 15:13:42 <rburton> funny because its true
Jun 15 15:13:48 <bluelightning> Crofton|work: it's more than just intel people in here...
Jun 15 15:14:34 <rburton> Crofton|work: i'll admit we do tell people to join #yocto instead of #oe.  if there were clear guidelines of what content is right for which channel we could update the guide…
Jun 15 15:14:47 <Crofton|work> openembedded is the build system
Jun 15 15:14:59 <Crofton|work> Yocto is the Project to embedded development easier
Jun 15 15:16:34 <joshuagl> yeah, I don't work for Intel...
Jun 15 15:16:49 <joshuagl> #oe always used to be noisier and less useful - has that changed? :-)
Jun 15 15:17:01 <rburton> joshuagl: you'll always work for intel, you just dont know that
Jun 15 15:17:26 <joshuagl> rburton: should I be expecting a paycheque?
Jun 15 15:17:39 <rburton> joshuagl: no
Jun 15 15:18:18 <joshuagl> then bah to you, says I!
Jun 15 15:18:59 <bluelightning> joshuagl: I'd say the two channels are about equal these days
Jun 15 15:19:34 <Crofton|work> It is annoying having to check who is in what channel
Jun 15 15:19:40 <bluelightning> joshuagl: I guess one thing that is very different about #oe now vs the old days is almost nobody talks about OE-Classic anymore
Jun 15 15:19:50 <bluelightning> joshuagl: which is of course a good thing :)
Jun 15 15:19:52 <joshuagl> \o/
Jun 15 15:20:59 <tripzero> joshuagl: !
Jun 15 15:21:27 <joshuagl> tripzero: !
Jun 15 15:22:08 <tripzero> oh hai :)
Jun 15 15:22:28 <tripzero> happen to know the proper way of adding python3 to an image?
Jun 15 15:22:51 <tripzero> I've got IMAGE_INSTALL_append = " python3" in my local.conf
Jun 15 15:23:16 <tripzero> but building the rootfs fails: ERROR: python3 not found in the base feeds (quark i586 x86 noarch any all).
Jun 15 15:26:08 <joshuagl> tripzero: I don't know about python, but IMAGE_INSTALL and friends want package names not recipe names. Maybe try a find in tmp/deploy/packages for python
Jun 15 15:26:24 <joshuagl> a quick `find -name *python*` in my packages dir reveals python-lang-2.7.9-r1.cortexa9hf_vfp_neon.rpm
Jun 15 15:26:33 <joshuagl> which I suspect is the name for the interpreter package
Jun 15 15:27:12 <tripzero> do i want to add via package name or recipe name?
Jun 15 15:28:02 <tripzero> i guess i could look at the python3 recipe
Jun 15 15:30:57 <tripzero> PACKAGES =+ "${PN}-pyvenv"
Jun 15 15:39:56 <tripzero> yep, that worked :)
Jun 15 15:42:05 <rburton> python3-modules is the metapackage to pull in all the modules
Jun 15 15:43:19 <rburton> and iirc python3-core is the interpretter
Jun 15 19:43:05 <cference> Hi! I'm　looking for documentation to help me cross-compile a project (OpenVSwitch) for yocto, can anyone guide me to one?
Jun 15 19:47:14 <rburton> the yocto documentation has examples on building
Jun 15 19:47:33 <rburton> but its very particular to each project.  step one is understanding how it builds normally.
Jun 15 19:48:25 <cference> Well, I tried building by passing specific arc and cross-compiler tools to make, but I think I might be missing the kernel source  in the things I specify
Jun 15 19:50:06 <zeddii_home> cference: are you talking about OVS .. i.e. the one that we alraedy have in meta-virtualization ?
Jun 15 19:50:28 <cference> ah, there's already something for OVS?
Jun 15 19:50:36 <rburton> good point, step 0 is check layers.openembedded.org
Jun 15 19:50:43 <zeddii_home> indeed. heavily used :)
Jun 15 19:50:50 <zeddii_home> OVS (and the layers.openembedded.org)
Jun 15 19:51:12 <zeddii_home> http://layers.openembedded.org/layerindex/branch/master/recipes/?q=openvswitch
Jun 15 19:51:37 <cference> oh great! Much appreciated... maybe next time I'll google a bit more instead of bugging you guys
Jun 15 19:57:09 <zeddii_home> no worries
Jun 15 20:49:46 <rburton> otavio: curious, what function in piglit was from xutil?
Jun 15 20:50:08 <otavio> rburton: I sent you the log
Jun 15 20:50:20 <otavio> xulfer: XVisual... or something
Jun 15 20:50:22 <otavio> oops
Jun 15 20:50:24 <otavio> rburton:
Jun 15 20:51:06 <rburton> hm, don't have the log in my mail if that's what you meant
Jun 15 20:56:25 <otavio> https://www.dropbox.com/s/fa3piiuamtg4vy7/log.do_compile.5179.gz?dl=0
Jun 15 21:04:18 <otavio> rburton:
Jun 15 22:08:57 <kergoth> damn, i keep getting OSError: [Errno 2] No such file or directory from the subprocess which spawns bitbake-worker, in the middle of my builds
Jun 15 22:09:00 <kergoth> or at least, a short way in
Jun 15 22:09:04 <kergoth> some tasks run fine
Jun 15 22:09:18 <kergoth> seemingly only after my latest updates of hte upstream layers, but will have to confirm
Jun 15 22:31:14 <rburton> kergoth: hm, i started seeing that this afternoon too
Jun 15 22:31:28 <rburton> which is weird as on friday it was fine, but now its breaking
Jun 15 22:33:38 <rburton> i've just tried backing down meta-oe as i did update that layer earlier, just in case something in there is upsetting things
Jun 15 22:44:47 <rburton> kergoth: fwiw, backing meta-oe to 9a5d25f2a717814f948b492b9c01c1ff0edb678d seems to stop it happening… may be unrelated, i didn't do lots of tests (about to go to bed leaving a series of builds running)
**** ENDING LOGGING AT Tue Jun 16 02:59:59 2015