**** BEGIN LOGGING AT Tue May 07 02:59:59 2013
May 07 07:41:23 <mckoan> good morning
May 07 08:18:34 <bluelightning> morning all
May 07 14:05:41 <Garibaldi> g'day all.  I have an issue while installing a custom SDK.  I see we have a patch to python to support multilib that intoduces a sys.lib variable.  In some cases, however, when I install an SDK, I'm not picking up a sys that has a lib
May 07 14:06:17 <Garibaldi> anyone have any idea what might cause this?
May 07 14:13:39 <Garibaldi> it's almost like it's not using the provided 'sys' module
May 07 14:13:55 <Garibaldi> but is using the provided sysconfig.py and site.py
May 07 14:14:29 <Garibaldi> odd thing is, it doesn't happen everywhere, which suggests something in the environment is hosing me
May 07 14:14:32 <Garibaldi> but I don't see what
May 07 14:18:05 <Garibaldi> but then I'm not a python guru, so maybe it's something else
May 07 14:27:03 <lpapp> hi, why is it good to use Yocto instead of for instance Ubuntu ARM nowadays on embedded?
May 07 14:34:44 <rburton> lpapp: flexibility mainly.
May 07 14:36:43 <lpapp> rburton: what flexibility?
May 07 14:37:29 <rburton> lpapp: complete flexibility as you're specifying the entire system.  ubuntu doesn't work on all arms, or MIPS at all, and you can't just tell ubuntu what cpu you've got and expect it to tune for it
May 07 14:38:51 <lpapp> rburton: I am just wondering because people put ubuntu-core onto the pandaboard, and so forth.
May 07 14:38:54 <rburton> if you use a "big" distro for your embedded product you're generally limited to taking their packages and making small changes
May 07 14:38:56 <rburton> sure they do
May 07 14:38:58 <lpapp> and they can install packages they need.
May 07 14:38:59 <rburton> and that's fine for experimenting
May 07 14:39:07 <lpapp> they can also capture the system onto a flash card anytime.
May 07 14:39:35 <rburton> and if you ship that you've almost certainly broken the GPL, which is fun
May 07 14:39:52 <lpapp> why would you?
May 07 14:40:10 <lpapp> (break GPL)
May 07 14:40:44 <rburton> it's almost impossible to satisfy the "full sources and build instructions" clause if you do 1) take existing image 2) tweak some packages 3) ship it
May 07 14:40:58 <lpapp> I am not sure I follow.
May 07 14:41:01 <rburton> but really that's a lame reason to use yocto
May 07 14:41:09 <rburton> everyone here uses yocto because it lets you build what you want
May 07 14:41:31 <rburton> not what canonical think a desktop OS should be, which you then have to tweak, bend and otherwise change into an embedded OS
May 07 14:41:33 <lpapp> ok, perhaps I had an environment where it did not matter.
May 07 14:41:42 <lpapp> perhaps, it was a micro optimization on the pandaboard.
May 07 14:43:21 <rburton> http://www.slideshare.net/rossburton/the-yocto-project is my presentation about YP, which has a few slides on why
May 07 14:43:29 <rburton> sadly the format doesn't work very well like that
May 07 14:44:39 <Garibaldi> in some ways you could take many of the arguments that the Gentoo folk use and use it for Yocto too
May 07 14:45:32 <rburton> yeah, we do share a common history if you go back far enough
May 07 14:46:14 <Garibaldi> yeah, I read that bitbake was inspired by portage, and the recipes do remind me a lot of ebuilds :-)
May 07 14:47:16 <rburton> afaik, it's more derived from instead of inspired by
May 07 14:47:42 <lpapp> so why not gentoo embedded then? :)
May 07 14:47:49 <rburton> http://www.slideshare.net/rossburton/why-you-should-use-the-yocto-project is my other presentation about why you should use YP, but the speakers notes are not that great
May 07 14:48:13 <rburton> lpapp: because YP has adoption and real-world use :)
May 07 14:48:22 <lpapp> means?
May 07 14:49:22 <rburton> yocto is a mature distro builder that's been used in numerous real products
May 07 14:50:42 <Garibaldi> hey, Google uses portage for ChromeOS -- I'd hardly call it "immature"
May 07 14:50:50 <lpapp> why did it need to derive from Gentoo?
May 07 14:51:09 <lpapp> not that I like gentoo that much myself, just asking.
May 07 14:51:26 <rburton> Garibaldi: i just said yocto was mature, no diss on gentoo
May 07 14:51:45 <Garibaldi> rburton: :-)
May 07 14:51:53 <rburton> lpapp: gentoo portage and bitbake share a common root, that's all
May 07 14:52:11 <Garibaldi> with Gentoo, you get Gentoo.  With YP you get whatever you want
May 07 14:52:44 <Garibaldi> YP gives you more flexibility in the end product
May 07 14:53:36 <Garibaldi> like the Montavista folks aren't going to make their distro Gentoo, but they might use YP to build their disto
May 07 14:56:18 <Garibaldi> I've actually toyed with the idea of using YP to build the Gentoo stage3 base system from scratch
May 07 14:56:19 <rburton> s/might/do/
May 07 14:56:33 <Garibaldi> rburton: granted
May 07 14:56:35 <rburton> monta vista carrier grade is yocto-compliant
May 07 14:57:10 <rburton> Garibaldi: i do wonder how many distros that now support aarch64 bootstrapped via yocto.  i know debian did.
May 07 14:57:43 <Garibaldi> it makes a ton of sense
May 07 15:00:27 <sgw1> YTPM: Saul is on
May 07 15:00:35 <zeddii> YPTM: Bruce Ashfield on the call.
May 07 15:00:41 <scottrif> YPTM: Scott rifenbark is on
May 07 15:00:45 <Song_Liu> YPTM: Welcome to the technical team meeting. Please let me know who's on the bridge. Thanks!
May 07 15:00:52 <laur> YPTM: Laurentiu Palcu joined
May 07 15:00:57 <bluelightning_> YPTM: Paul Eggleton joined
May 07 15:00:57 <tomz1> YPTM: Tom here
May 07 15:01:05 <RP> YPTM: Richard is on the call
May 07 15:01:18 <Zagor> YPTM: Björn Stenberg joined
May 07 15:01:35 <rburton> YPTM: ross is on the call
May 07 15:01:41 <pidge> YPTM: Beth is dialing in now
May 07 15:01:44 <bluelightning> YPTM: Paul Eggleton joined
May 07 15:01:57 <denix> YPTM: Denys is here
May 07 15:02:04 <belen> YPTM: belen is here
May 07 15:02:13 <strassek> YPTM: Kevin Strasser is here
May 07 15:02:34 <jzhang-laptop> YPTM: jzhang's on the call
May 07 15:03:15 <Song_Liu> YPTM: Opens from anyone?
May 07 15:03:28 <fray> YPTM: Mark is here...
May 07 15:03:40 <bluelightning> YPTM: 1.4.1
May 07 15:04:02 <dvhart> YPTM: Darren has joined
May 07 15:04:06 <nitink> YPTM: Nitin joined the bridge
May 07 15:04:27 <sgw1> fray: morning, I was able to reproduce that rpm macros issue that was filed yesterday against 1.4, mkdir and mkdir_p are pointing to different places (/bin and /usr/bin)
May 07 15:04:57 <fray> my suggestion for an easy fix.. mkdir_p should be %{_mkdir} -p in the macros.in file
May 07 15:05:01 <fray> that should fix it
May 07 15:05:04 <fray> (and be an easy change)
May 07 15:05:34 <adamian> adamian on IRC, not on call - can't get the desk phone to work :(
May 07 15:05:36 <Ramana_> joined YPTM
May 07 15:05:38 <sgw1> I will work on that, I think it might be a host contamination issue
May 07 15:05:54 <fray> I'm sure it is.. but fixing th macros.in is by far the easiest approach
May 07 15:07:44 <Corneliu> YPTM: Corneliu joined
May 07 15:08:17 <sgw1> bluelightning: there is a patch that you will need to pick up from me shortly
May 07 15:09:52 <bluelightning> sgw1: ok
May 07 15:11:25 <rburton> dvhart: i have a screenie of shutdown crashing on qemux86 for when you're around properly
May 07 15:14:04 <rburton> dvhart: also apologies for not replying to that mail - silence is compliance as they say :)
May 07 15:14:52 <dvhart> rburton, go ahead and point me at the screenshot
May 07 15:15:17 <dvhart> and nobody need apologize to me for missing something, I'm dropping balls on the ground more than I'm catching them lately :-)
May 07 15:15:28 <rburton> dvhart: trying to get netconsole through a qemu working to get more than one screen
May 07 15:15:41 <dvhart> why not use serial?
May 07 15:15:47 <dvhart> -nographic ?
May 07 15:15:48 <fray> YPTM: is the 1.5 planning on wiki yt?
May 07 15:16:27 <rburton> dvhart: http://imgur.com/hQXxIAk
May 07 15:16:36 <Song_Liu> https://wiki.yoctoproject.org/wiki/Planning
May 07 15:16:47 <lpapp> rburton: I should probably do a feasibility study whether we need Yocto.
May 07 15:17:12 <lpapp> one thing is that we need the socketcan driver, so we would need to customize the kernel anyway, but you can do that for Ubuntu as well, I believe.
May 07 15:17:12 <dvhart> rburton, yeah, try running with -nographic and logging the output from the console
May 07 15:17:32 <dvhart> but you did at least get the entire stack trace
May 07 15:17:38 <dvhart> which is very fortunate :-)
May 07 15:18:04 * zeddii hears short meeting and perks up.
May 07 15:18:22 <dvhart> rburton, I see "native_machine_*".... is this with or without paravirt?
May 07 15:19:23 * scottrif has to bail for practice - later.
May 07 15:21:21 <rburton> dvhart: with, this is stock qemux86
May 07 15:22:20 <adamian> adamian managed to phone in
May 07 15:23:28 <dvhart> rburton, paravart is a kernel config
May 07 15:23:39 <dvhart> oh... you mean the stock BSP
May 07 15:23:41 <dvhart> right, got it :)
May 07 15:23:59 <rburton> dvhart: so far i've managed to replicate just once so we could blindly flip like we did on x86-64...
May 07 15:24:18 <dvhart> I'm looking at the trace...
May 07 15:26:07 <Corneliu> https://wiki.yoctoproject.org/wiki/1.4_QA_Status
May 07 15:26:41 <dvhart> rburton, do you have this build lying around?
May 07 15:26:51 <dvhart> can you do an addr2line on c101d327 ?
May 07 15:27:12 <sgw1> Song_Liu: Please ensure you add that link to the updated "Releases" page please.
May 07 15:28:28 <rburton> dvhart: ha, got it in a console
May 07 15:28:35 <dvhart> better :)
May 07 15:28:58 <rburton> not a lot better than the screenie
May 07 15:29:15 <dvhart> you should have stack and register content
May 07 15:29:40 <rburton> dvhart: http://pastebin.com/e12S8z5h
May 07 15:29:42 <Song_Liu> YPTM: Thank you all for joining the meeting. Have a nice day/evening!
May 07 15:29:47 <rburton> dvhart: that's just noise to me ;)
May 07 15:32:21 <dvhart> rburton, can you try the addr2line?
May 07 15:32:38 <dvhart> that will help me see where it's failing in stop_other_cpus
May 07 15:33:18 * rburton tries to remember how that works
May 07 15:35:32 <rburton> dvhart: just building binutils
May 07 15:35:57 <rburton> oh i can do it on the build host
May 07 15:35:59 <dvhart> oh, I figured you could just do it on your build machine
May 07 15:36:01 <dvhart> yeah :-)
May 07 15:37:11 <rburton> just got to find it all :)
May 07 15:40:56 <rburton> dvhart: you've got private messages
May 07 18:19:00 <madhura> pidge: I wanted help in preparing my application for opw that needs to be submitted tomorrow
May 07 19:25:38 <evanp> is there something I don't understand about variable expansion? "${@'${SRC_URI}'}" works, but "${@'${SRC_URI}'.split()[0]}" doesn't (the internal variable reference expands to '')
May 07 19:29:07 <kergoth> nope, there's nothing inherently wrong with that. but it depends on *when* the expansion occurs, too
May 07 19:29:19 <kergoth> also, you can use the python identifier bits to simplify
May 07 19:29:26 <kergoth> ${@SRC_URI.split()[0]}
May 07 19:30:13 <feydrautha80> can i override PACKAGES in my recipe ?
May 07 19:30:37 <kergoth> you can override any config variable in a recipe. that's how the metadata works
May 07 19:31:00 <kergoth> but doing so is wrong in nearly all cases :)
May 07 19:31:09 <evanp> kergoth: I didn't change any details other than to add ".split()[0]" to that line of my bbclass...I would have thought 'when' would be exactly the same, given that
May 07 19:32:16 <kergoth> evanp: yes, that's correct. the two will behave exactly the same, so you must have something else going on, or a gap in your understanding. i'd split out the work into a def'd function so you can bb.warn()
May 07 19:36:36 <feydrautha80> thank you
May 07 19:50:45 <evanp> kergoth: about that foo="${@SRC_URI}" trick: is the parser aware that the expression depends on ${SRC_URI}, or do I need to set foo[vardeps] when I use that form? I'm not really clear on how smart it is, or really how it works in general....
May 07 20:04:38 <kergoth> evanp: iirc it does check use of python identifiers. if not, it's a bug :)
May 07 20:05:40 <evanp> kergoth: okay, thanks much. (figured out my issue too, def + bb.warn was an excellent idea)
May 07 20:05:50 <kergoth> ah, glad to hear it
May 07 20:09:51 <kergoth> evanp: hmm, checking the code, it looks like it might be missing it, so i stand corrected. I suspect it may have been postponed due to a desire to be smart about it, that is, don't catch every identifier, just ones that aren't also defined in the code, but then there's the question of scope to be concerned with
May 07 20:10:04 <kergoth> and that form is only valid in ${@}, not other contexts of python code..
May 07 20:10:09 * kergoth digs further to verify
**** ENDING LOGGING AT Wed May 08 02:59:58 2013