**** BEGIN LOGGING AT Tue Nov 05 02:59:58 2013 Nov 05 08:09:00 hm patchwork seems to have problems again Nov 05 08:45:02 morning all Nov 05 08:57:48 ant_work: hi, you pinged me yesterday Nov 05 09:11:22 gm Nov 05 09:11:44 yes, I'm back now and I'd merge your work for h1940 Nov 05 09:12:02 kernel 3.12 is ok? what about userspace? Nov 05 09:51:39 morning all Nov 05 11:42:54 hi bluelightning, hi all Nov 05 12:53:22 when I try to run something inside gdb, I always get the message "warning: Could not load shared library symbols for linux-gate.so.1." Nov 05 12:53:38 gdb works fine, and it finds all the other debug symbols and source files automatically Nov 05 12:53:57 Am I the only one with this problem? What happens to you guys when you try to run "gdb /bin/cp" and then type run? Nov 05 12:54:35 (on a debug build) Nov 05 15:11:39 hi all. I have build linux kerenel, and I have one message: Summary: There was 1 WARNING message shown. How to see this warning? I.e. - where to look for the log? Nov 05 15:21:05 hi, all! Nov 05 15:21:34 is IMAGE_DEPENDS_... vars are still handled or there is some changes regarding this? Nov 05 15:25:03 I mean IMAGE_DEPENDS_ stuff is no longer built and installed, at all, it seems that variable is ignored. Nov 05 15:26:04 slapin: image_types.bbclass does read it Nov 05 15:28:47 bluelightning: a problem is that it was working a few hours ago and stopped.I have parted-native in IMAGE_DEPENDS_ var, and when I do bitbake -g then grep parted *.dot, there is no result, so it is not mentioned anywhere... Nov 05 15:30:00 bluelightning: details: I use meta-allwinner BSP, in this way it is idential to raspberry pi one, they both use bbclass file to build special sdcard images Nov 05 15:32:59 slapin: I don't think those will show up in "bitbake -g" because the overrides don't get applied until the part of do_rootfs that actually creates the output images is run Nov 05 15:33:53 bluelightning: https://github.com/ebutera/meta-allwinner/blob/master/classes/sdcard_image-a10.bbclass is not working Nov 05 15:34:22 bluelightning: it doesn't build IMAGE_DEPENDS there. Nov 05 15:34:50 bluelightning: if I build them by hand with bitbake command, everything works Nov 05 15:35:05 bluelightning: so I wonder... Nov 05 15:37:24 bluelightning: the machine conf: https://github.com/ebutera/meta-allwinner/blob/master/conf/machine/cubieboard.conf Nov 05 15:39:11 slapin: I'm not sure; I think someone will just need to debug it Nov 05 15:39:25 slapin: the variable has not been deprecated though Nov 05 15:39:36 bluelightning: how can I debug this? Nov 05 15:40:58 slapin: I would start by putting some bb.warn() calls in imagetypes_getdepends() in image_types.bbclass to see what that code is seeing Nov 05 15:47:16 bluelightning: how can I print the variable with bb.warn()? Nov 05 15:48:04 slapin: bb.warn('variable value is %s' % d.getVar('SOMEVARIABLE', True)) Nov 05 15:50:39 bluelightning: e2fsprogs-native:do_populate_sysroot sunxi-board-fex:do_populate_sysroot xz-native:do_populate_sysroot Nov 05 15:51:03 bluelightning: this is result from bb.warn(deps) at end of function Nov 05 15:51:36 so really, depends from IMAGE_DEPENDS are not added Nov 05 15:52:37 slapin: the only thing I can suggest is at that point IMAGE_FSTYPES is not the value you think it should be Nov 05 15:52:47 slapin: use bitbake -e to check that Nov 05 15:54:39 bluelightning: https://github.com/naguirre/meta-allwinner/blob/master/classes/sdcard_image-a10.bbclass, IMAGE_DEPENDS_a10-sdimg value is ignored Nov 05 15:55:19 slapin: have you checked what IMAGE_FSTYPES ends up as? Nov 05 15:56:49 bluelightning: IMAGE_FSTYPES="ext3 tar.gz a10-sdimg tar.xz" Nov 05 15:57:07 bluelightning: as bitbake -e suggests Nov 05 15:58:21 slapin: I'm afraid I don't have time to dig into this right now Nov 05 15:58:32 slapin: you can see that the code *does* read that variable however Nov 05 15:59:03 bluelightning: yes, and image builds properly, but dependencies are ignored Nov 05 15:59:59 slapin: try printing IMAGE_FSTYPES in that code Nov 05 16:02:35 bluelightning: fill bitbake environment http://ossfans.org/envdata Nov 05 16:03:39 s/fill/full Nov 05 16:03:54 bluelightning: I mean full environment Nov 05 16:07:09 slapin: the critical thing is what is the value at that point in the execution Nov 05 16:08:20 bluelightning: in progress, as it is a bit time consuming... Nov 05 16:09:33 bluelightning: at time of execution it is still "ext3 tar.gz a10-sdimg tar.xz" Nov 05 16:21:29 slapin: I don't know then; sorry... it seems like a bug Nov 05 16:28:02 bluelightning_: ah, I found what that was! it was overrides. I can't understand why it worked before... Nov 05 16:28:17 bluelightning_: thanks a lot for pointers! Nov 05 16:56:04 Public OE Technical Steering Committee/Workgroup meeting starts in here in approximately 5 minutes; everyone is welcome to participate Nov 05 16:59:49 khem: koen: fray: RP: roll call, who's here? Nov 05 17:00:06 aye Nov 05 17:00:10 bluelightning: I'm here Nov 05 17:00:23 * rburton is lurking Nov 05 17:01:14 #startmeeting Nov 05 17:01:14 Meeting started Tue Nov 5 17:01:14 2013 UTC. The chair is bluelightning. Information about MeetBot at http://wiki.debian.org/MeetBot. Nov 05 17:01:14 Useful Commands: #action #agreed #help #info #idea #link #topic. Nov 05 17:01:58 #chair RP koen khem fray Nov 05 17:01:58 Current chairs: RP bluelightning fray khem koen Nov 05 17:02:36 so, I think we are sans any specific agenda for this meeting, unless someone has something prepared? Nov 05 17:03:13 bluelightning: well, the topic Jack mentioned at the GA should be on the agenda Nov 05 17:03:31 we can briefly talk about planning around the next release Nov 05 17:03:53 Does anyone else have anything they want to talk about? Nov 05 17:05:16 shoeleather? Nov 05 17:05:22 I would like to include lava Nov 05 17:05:31 we can expand that to automated testing Nov 05 17:05:37 ok Nov 05 17:06:38 any volunteers to chair? Nov 05 17:07:30 bluelightning: I can do if nobody else wants to Nov 05 17:07:36 RP: thanks Nov 05 17:08:28 Ok, first topic is what jack mentioned at the GA - the OE website would use some tweaks Nov 05 17:08:34 and the landing page shouldn't be a wiki Nov 05 17:08:42 is jackmitchell around? Nov 05 17:09:07 #topic website Nov 05 17:09:20 Personally, I agree with what he mentioned and support changing it to explain OE's position relative to other projects like Yocto Nov 05 17:09:34 I think this would reduce some new user confusion Nov 05 17:09:46 yep, FWIW I agree Nov 05 17:09:56 Anyone have anything they want to add? Nov 05 17:10:21 at the same time we still have a lot of junk left to be cleared out of the wiki, something Jack also mentioned Nov 05 17:10:32 RP: its about resourcing the website work Nov 05 17:10:33 I'd back Jack in going forward to improve it and am happy to review the changes Nov 05 17:10:46 khem: ok, how do we resource it? Nov 05 17:11:12 since he's not piped up yet I'll say I'm guessing he hasn't actually signed up to do all of the work... ;) Nov 05 17:11:14 wiki has edit rights but I dont know how can we do with static website Nov 05 17:11:29 khem: you didn't get a chance to see the quick mockup that Jack mitchell did. It was quite an improvement. Nov 05 17:11:45 I would be happy if someone is working on getting the website improved Nov 05 17:11:51 khem: give a limited number of people ssh access to be able to change the front page? Nov 05 17:12:08 RP: I agree. I would suggest that we give him the chance to come up with something and see what he comes up with. Nov 05 17:12:08 RP: yes thats a way to go Nov 05 17:12:10 the question is how much jack can help I guess and if anyone else is willing Nov 05 17:12:12 one approach could be to make it a git repository that certain people can push to Nov 05 17:12:17 and if there are interested folks we should do it Nov 05 17:12:22 yes, git repo would work Nov 05 17:12:47 I brought this up here as I'd like to back someone willing to help improve things Nov 05 17:13:06 khem: would you be able to help on the admin side of setting up a git repo? Nov 05 17:13:15 khem: or might Tom be able to help with that? Nov 05 17:13:23 in case anyone isn't clear, the proposal isn't to throw out the wiki, just not to have the main part of the website be entirely wiki-based Nov 05 17:13:43 right, the front page in particular Nov 05 17:14:21 RP: yes he should Nov 05 17:14:37 I'd stress that the core of the people on the TSC are all overworked and really need help from others, that is one of the points of openening up these meetings Nov 05 17:14:47 RP: interested folks can send ssh pub keys to him Nov 05 17:15:01 and I will wire him in Nov 05 17:15:38 ok, lets hope jack reads the discussion and sends his first draft out, we could then get it into the git repo and get him and a few others access to that repo Nov 05 17:15:51 #topic next release Nov 05 17:15:54 yes and i will encourange more folks Nov 05 17:16:35 We're in the final stage of planning what happens in the next six months in the Yocto Project which obviously significantly affects OE-Core Nov 05 17:16:54 The work items are in the bugzilla, the focus on the medium+ and highs Nov 05 17:17:28 https://wiki.yoctoproject.org/wiki/Yocto_1.6_Features Nov 05 17:17:39 RP: I will file some bugs/feature requests Nov 05 17:17:40 Any questions or anything anyone wants to discuss? Nov 05 17:18:03 khem: Is there anything in particular you think Juniper might be contributing in the 1.6 timeframe? Nov 05 17:18:19 RP: a request I will have is to change default qemu emulation for arm from armv5te to armv7a Nov 05 17:18:41 khem: based on what reason? Nov 05 17:18:49 RP: with automated testing Nov 05 17:19:45 RP: armv7 is now more prevelant than v5 Nov 05 17:20:06 khem: doesn't that mean armv5 will effectively cease to get tested though? Nov 05 17:20:12 yes Nov 05 17:20:27 is there any performance issue using a "heavier" instruction set like v7? Nov 05 17:21:03 Anyhow, we can discuss this on the mailing list. I don't see any fundamental reason against changing, equally some tests and numbers would be good Nov 05 17:21:16 RP: quick question, the yocto 1.6 features includes bitbake command-line improvements, would integration of something like mentor's 'bb' tool be in line with that, either led by us or others? I think there's a yocto bug for that, but it's not listed in the 1.6 features page Nov 05 17:21:25 khem: please do file an enhancement bug and cc Bruce on that one Nov 05 17:21:39 speaking of qemu, did the update patch go in yet? Nov 05 17:21:46 * rburton seconds integration of bb in some form Nov 05 17:22:12 kergoth: its specifically mentioned in https://bugzilla.yoctoproject.org/show_bug.cgi?id=3433 :) Nov 05 17:22:36 kergoth: so yes, the exact form we do it in and who does it needs discussion but the idea is there Nov 05 17:22:38 RP: i think v5 is diminishing return Nov 05 17:22:50 koen: its about to Nov 05 17:22:58 khem: can we introduce v7 with different MACHINE name like qemuarmv7a.conf? Nov 05 17:22:59 v7 gets up more testing for majority use case Nov 05 17:23:00 ah, okay, i didn't spot it since its not interactive, though clearly the framework would work for both operating modes Nov 05 17:23:03 thanks Nov 05 17:23:21 kergoth: Right, its all related Nov 05 17:23:32 * kergoth nods Nov 05 17:23:58 ok, moving on Nov 05 17:24:03 #topic shoe leather Nov 05 17:24:07 darknighte: ? Nov 05 17:24:15 yep? Nov 05 17:24:27 JaMa: that machine exists i am proposing to make it default in oe-core Nov 05 17:24:27 darknighte: you wanted to discuss it? Nov 05 17:24:58 I had a interactive session last week with halstead. Nov 05 17:26:27 khem: I know it existed, but currently it doesn't in oe-core, so I was trying to say that current qemuarm.conf should stay or be renamed to qemuarmv5.conf or something for people who still care (and even have some v4,v5 devices :)) Nov 05 17:26:34 he's looking at taking one of the boards and pushing the images from the ab over.. Nov 05 17:26:34 we've had minimal usage of the lab and i'd like to see that change, if possible. Nov 05 17:27:09 darknighte: We're missing the glue logic for this. As we've both discussed several times over, this needs a developer to work on it Nov 05 17:27:46 darknighte: There are discussions happening about what to do with automated hardware testing in 1.6 but its a problem that will need developers working on it and its not simple :/ Nov 05 17:28:00 I guess we should mention lava now as well, talk about both together Nov 05 17:28:03 #topic lava Nov 05 17:28:09 khem: ? Nov 05 17:28:25 RP: glue logic only really applies for using it for autobuild verifictions. I would like to see more individuals looking at it too. Nov 05 17:28:53 darknighte: any idea why people aren't doing so? Nov 05 17:29:17 RP: not sure. Nov 05 17:29:40 lack of public knowledge? lack of interest? Nov 05 17:29:47 security concerns? usage issues? Nov 05 17:29:52 darknighte: the question is how do you get individuals looking at it. Perhaps announce it again on the mailing list and explain how people can get access? Nov 05 17:29:55 I don't have really any data. Nov 05 17:30:42 darknighte: I learned quite a lot about lava lately Nov 05 17:30:48 re lava, I have been looking at it lately as well Nov 05 17:30:54 and shoeleather can act as a board farm managed by lava Nov 05 17:30:54 darknighte: I'm not sure how to help as I don't know why either Nov 05 17:31:16 and lava instance could be running inside mentor which is talking to main lava front end Nov 05 17:31:24 may be at yp.org Nov 05 17:31:28 * darknighte nods Nov 05 17:31:28 I guess that's the best option for now. Nov 05 17:31:28 I would really like to get some "beta testers" to use it and give feedback. Nov 05 17:31:28 My guess is that the whole VPN structure is overly restrictive and will need to be changed, but without feedback, it makes it difficult. Nov 05 17:31:32 khem: I've heard a lot of talk about lava recently. In principle the idea seems good, I do worry about some of the challenges in making it really work for OE/YP though Nov 05 17:31:42 anyway, unless anyone else has thoughts, I'll let that go. Nov 05 17:31:54 khem: indeed. I had a similar thought. Nov 05 17:31:59 RP: they have done tonne of work around h/w testing Nov 05 17:32:10 darknighte: perhaps mail some of the lists and see if you can attract some users? Nov 05 17:32:20 I'm not overly keen on the way lava has been written (*lots* of things are hardcoded) Nov 05 17:32:26 khem: one of the primary linaro guys that works with lava lives near me. Nov 05 17:32:28 khem: I know they have, the question is whether it will work for what we need Nov 05 17:32:33 we've had lunch a couple of times. Nov 05 17:32:35 but I can see some potential, particularly in the lava-dispatcher component Nov 05 17:32:44 khem: I took a look and saw hardcoding and docs with read "TBD" Nov 05 17:32:49 bluelightning: the amount of work to create a parallel universe is cumbersome Nov 05 17:32:57 and lava is open for contribution Nov 05 17:33:14 and we can influence its design and directions Nov 05 17:33:16 khem: The question is more whether we can have enough influence to make it work for what we need Nov 05 17:33:19 khem: yes, we'd want to think twice before writing anything new Nov 05 17:33:28 RP: totally Nov 05 17:33:33 khem: or whether they just care about ARM, launchpad integration and so on Nov 05 17:33:45 the devs were dying to have help Nov 05 17:33:55 khem: what devs aren't? Nov 05 17:33:58 ;) Nov 05 17:34:02 hm and ciao again Nov 05 17:34:58 RP: the ARM centric thing shouldn't be too much of an issue, given the problem space we're dealing with. Nov 05 17:36:08 darknighte: I will respectfully disagree with that Nov 05 17:36:57 if we were to try to make use of something existing, LAVA seems like the most promising candidate for us I think, but it's not going to be drop-in Nov 05 17:37:09 darknighte: Certainly YP aims to be architecture neutral, this has been a concern time and time again and I don't plan to change that now Nov 05 17:37:14 RP: perhaps I am confused,. how would it be a problem? Nov 05 17:37:26 RP: no, its not ARM centric, they support minnow and x86 blades, qemus as targets Nov 05 17:37:26 bluelightning: agreed, but as a starting point, it seems like a pretty decent candidate. Nov 05 17:37:34 APIs are meant to be generic Nov 05 17:37:43 RP: see khem's points Nov 05 17:38:16 darknighte: right, I just want to be clear there is a requirement here to support that Nov 05 17:38:20 RP: as i said, I've spoken with one of the primary authors and LAVA is written to be generic. Nov 05 17:38:36 RP: and to our advantage lava devs are now starting to use OE based distro Nov 05 17:38:42 for testing Nov 05 17:38:53 so there is lot of common area of work Nov 05 17:39:12 Definitely worthy of further research Nov 05 17:39:13 RP: in the problem space of automated testing, the specifics of the target under test of farily small, e.g. testing on minnow or beaglebone look very similar, for example. Nov 05 17:39:50 darknighte: yes and no :) But I understand what you're saying. You could read some of the earlier comments in different ways Nov 05 17:39:55 RP: they have EFI and u-boot taken care of while booting targets Nov 05 17:40:03 they would need help with other bootloaders e.g. Nov 05 17:40:20 I'm less concerned about ARM centricity and more about how it has been structured; there's not nearly enough abstraction Nov 05 17:40:21 so if we have a board that uses a different bootloader then we could enhance it Nov 05 17:40:33 there are android support pieces scattered throughout the code Nov 05 17:40:50 (talking about the dispatcher specifically) Nov 05 17:40:55 bluelightning: That is a helpful data point Nov 05 17:41:04 RP: khem: the real rub comes from resourcing Nov 05 17:41:04 same as for shoeleather. Nov 05 17:41:39 darknighte: right, so the question is whether there are people with time to work on this? Nov 05 17:41:47 bluelightning: indeed. that's one of the things that they'd welcome help with. Paul actually lamented that a bit. Nov 05 17:41:56 RP: exactly Nov 05 17:42:30 moin Nov 05 17:42:34 bluelightning: yes, they have seen that OE is in so much match with their needs Nov 05 17:42:43 like h/w packs wont be needed etc. Nov 05 17:42:52 images can be run straight Nov 05 17:42:52 All I can suggest right now is that people who have some time to experiment do so and we collect up a list of discussion points we could take to the lava developers Nov 05 17:43:14 yep, I think we need to take this back to the mailing list Nov 05 17:43:24 yes I will have some study scheduled for next week Nov 05 17:43:28 We can go around in circles here but we need real data Nov 05 17:43:31 bluelightning: agreed. Nov 05 17:43:45 ok, so take to the mailing list Nov 05 17:43:54 Any other topics anyone wants to bring up? Nov 05 17:43:55 sure sounds good Nov 05 17:43:56 RP: I would suggest that we emphasize the need for a QA mentality here. Nov 05 17:44:39 darknighte: we do have some QA people in the project and I've asked the take a look Nov 05 17:44:51 darknighte: QA does feature highly on the 1.6 plans Nov 05 17:45:37 If no other business I'll close the meeting... Nov 05 17:45:37 * darknighte nods Nov 05 17:46:08 * RP suspects bluelightning knows the magic command Nov 05 17:46:13 #endmeeting Nov 05 17:46:13 Meeting ended Tue Nov 5 17:46:13 2013 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) Nov 05 17:46:13 Minutes: oe/2013/oe.2013-11-05-17.01.html Nov 05 17:46:13 Minutes (text): oe/2013/oe.2013-11-05-17.01.txt Nov 05 17:46:13 Log: oe/2013/oe.2013-11-05-17.01.log.html Nov 05 17:46:26 heh, obvious :) Nov 05 17:46:50 it was an educated guess, I only vaguely remembered :) Nov 05 17:46:56 btw, where are meetings stored? Nov 05 17:47:19 slapin: The minutes get mailed to the members list and are on the wiki IIRC Nov 05 17:48:27 RP: which wiki, YP or OE? Nov 05 17:49:37 slapin: OE Nov 05 17:50:06 RP: thanks! Nov 05 17:52:04 I believe that the minutes from the public meetings should already be accessible; I just don't have the URL handy Nov 05 17:52:16 well, s/minutes/logs/ Nov 05 17:52:39 Crofton|work: perhaps you have the URL? Nov 05 17:54:30 RP what git repo needs setting up? Nov 05 17:55:26 ka6sox: something for the front page of the OE website Nov 05 17:55:38 ka6sox: so we could have a static html page as the landing page Nov 05 17:55:55 okay, i'll set that up...who gets access? Nov 05 17:56:28 RP, darknighte: fwiw, there will be an x86 instance in LAVA soon Nov 05 17:56:56 all LAVA docs were rewritten last week, so let us know if something is missing Nov 05 17:57:03 koen: good to hear Nov 05 17:57:11 koen: you working with Paul? Nov 05 17:57:21 koen: there are a lot of broken doc links still... Nov 05 17:57:45 bluelightning: yes, they deleted all the old docs and started from scratch Nov 05 17:59:33 kergoth, bluelightning: I'm toying with the idea of something like http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t2&id=acf9f2065b6a15836951f2c8b96bd89832ef64ca Nov 05 18:00:25 kergoth, bluelightning: Any thoughts on it? Its slightly ugly in that it exports a dict as a variable value. Equally the contents makes most sense that way and I think the data there could be useful for a variety of things in the task Nov 05 18:00:40 Top of my list, figuring out which m4 files a given recipe should see Nov 05 18:02:03 ah, so a task would be able to access its own dependencies at runtime, that does open up a number of interesting possibilities, without having to do quite as much poking into pkgdata for example Nov 05 18:02:07 hmm Nov 05 18:02:56 hmm, interesting Nov 05 18:03:18 RP: any significant performance/memory usage impact? Nov 05 18:03:42 bluelightning: not measured yet. I doubt the memory use is much though Nov 05 18:04:39 kergoth: means we could do sysroot per recipe for example Nov 05 18:04:54 using hardlinks and a master copy of each manifest Nov 05 18:05:21 * kergoth nods Nov 05 18:05:46 would also make it easier to do things like compare the automatic rdeps vs what we actually dep on, to catch implicit deps Nov 05 18:05:49 in theory Nov 05 18:06:04 kergoth: yes Nov 05 18:06:26 * RP heads afk for a bit Nov 05 18:06:44 If anyone does have thoughts I'll scroll back later though... Nov 05 18:07:15 kergoth: I was just thinking the same thing :) Nov 05 18:07:19 hi, I need some good arguments for upgrading a company project from danny to dora Nov 05 18:08:31 currently I have: (1) danny will start to break more and more over time on current and future distros (2) tons of bugs were fixed since then (3) dora is considerably faster (4) dora contains gstreamer 1.0 recipes already & 1.2 will follow soon (the project requires gstreamer 1.0) (5) several patches we backported wouldnt have to be carried around anymore Nov 05 18:09:22 dv_: these may be of interest: https://lists.yoctoproject.org/pipermail/yocto-announce/2013-April/000027.html Nov 05 18:09:23 https://lists.yoctoproject.org/pipermail/yocto/2013-October/018879.html Nov 05 18:25:36 koen: is the documentation posted online somewhere? Nov 05 18:25:44 other than in git that is Nov 05 18:31:45 bluelightning: I don't know, I've only looked at the git stuff Nov 05 18:31:50 bluelightning: I'll have a look tomorrow Nov 05 18:32:04 since I'm supposed to know all this :) Nov 05 18:32:35 ok, np Nov 05 18:33:30 koen: if it is you might want to poke someone to update the link at the bottom of the description on https://launchpad.net/lava so it links to the right place ;) Nov 05 18:35:39 damn it Nov 05 18:35:44 I need to read the scroll back Nov 05 18:35:52 jackmitchell, needs to get on the members list Nov 05 18:35:58 he pinged me alread Nov 05 18:36:22 mckoan|away, can youo send me the email address your friend from the GA would like on the members list? Nov 05 18:39:10 bluelightning: https://wiki.linaro.org/Platform/LAVA Nov 05 18:39:17 is the place to start Nov 05 18:39:23 as I am told Nov 05 18:39:29 yeah Nov 05 18:39:43 I am actually interested in looking at it to do some x86 test also Nov 05 18:40:02 and may be https://wiki.linaro.org/Platform/LAVA#LAVA_Documentation Nov 05 18:40:07 to be specific Nov 05 18:40:32 I have FRI2 which is sitting here running angstrom Nov 05 18:41:40 I was wondering about trying to get shoe leather setup with lava Nov 05 18:41:53 that would be awesome Nov 05 18:41:58 it would be a good test case Nov 05 18:42:08 but actually, I can have my 3 boards hooked up and exposed to folks Nov 05 18:42:14 and so can everyone Nov 05 18:42:27 and we can have a large pool of test hardware Nov 05 18:42:49 and once they have m:n instances implemented for lava Nov 05 18:43:04 that means I have a master and you have your own controlling your boards Nov 05 18:43:04 the biggest annoyance so far is the install i subuntu centric Nov 05 18:43:22 * Crofton is seriously annoyed by this Nov 05 18:43:27 but my dashboard could use some of your boards and you could use sme of mine Nov 05 18:43:35 I guess that is why vm's were invented Nov 05 18:43:43 yep Nov 05 18:43:49 some battles are not worth fighting for Nov 05 18:44:03 there is an open bug for it though Nov 05 18:44:41 ok, I need to do a real task first Nov 05 18:44:49 then poke at the vm Nov 05 18:45:12 the issues I see with LAVA: Nov 05 18:45:19 seems to like jenkins Nov 05 18:45:24 ubuntu install Nov 05 18:45:32 hard to get my head around how to instal Nov 05 18:45:54 notice I do not say, seems to favor specific archs Nov 05 18:46:16 Crofton: see what I said in the meeting Nov 05 18:47:59 khem: OE supports more than just Ubuntu; if we're to have a companion testing framework it would be sensible for that to be able to work on the same platforms Nov 05 18:48:18 sure Nov 05 18:49:16 * Crofton is not an Ubuntu person in anyway Nov 05 18:49:47 we need to figure out how to do a good eval fairly quickly Nov 05 18:51:42 Crofton: bluelightning: i would support the idea of LAVA being a bit more independent from ubuntu, too. all our infrastructure is based on ubuntu LTS, that's probably why it is this way... but i am sure this can be changed. Nov 05 18:53:27 ndec: that's good to hear Nov 05 18:53:35 Crofton: you want to do an eval of LAVA 'server' side, or just playing with some boards? Nov 05 18:53:57 you remember that we offered you to play with http://community.validation.linaro.org/, if needed. Nov 05 18:54:04 * bluelightning -> home Nov 05 18:54:05 ah thanks for that url Nov 05 18:54:08 bbl Nov 05 18:54:10 gn Nov 05 18:54:42 Crofton: i don't find the address with the most recent documentation that we had shown you. Nov 05 18:54:44 that url says 404 Nov 05 18:54:47 but seems to work Nov 05 18:55:16 http://community.validation.linaro.org/dashboard/test-definition/ Nov 05 18:55:41 we really need to be able to bitbake lava-image and have it work :) Nov 05 18:56:03 ok, I need to do some real work for a bit Nov 05 18:56:09 then I can pokemmore at this Nov 05 18:56:26 ok. Nov 05 18:56:37 i need to do the same thing, too ;-) Nov 05 19:32:58 I have a system with both gcc 4.7 and 4.8 installed, and want to let OE build everything with gcc-4.7 instead of 4.8 Nov 05 19:33:13 should I edit bitbake.conf and modify the "export CC" line ? Nov 05 19:33:33 no Nov 05 19:33:46 the build machine' scompiler is only used for certain recipes (native, cross) Nov 05 19:33:49 (I dont mean a different cross compilation toolchain; I mean the compiler to use for building the native stuff) Nov 05 19:33:52 you'll want to alter BUILD_CC Nov 05 19:34:02 inside local.conf ? bitbake.conf ? Nov 05 19:34:10 never touch bitbake.conf Nov 05 19:34:13 perio Nov 05 19:34:14 d Nov 05 19:34:31 bitbake doesn't care where something is defined, other than ordering. where something belongs is a convention Nov 05 19:34:41 local.conf or site.conf are best in this case Nov 05 19:34:59 so I add "export CC=gcc-4.7" in local.conf Nov 05 19:35:00 okay Nov 05 19:35:05 no Nov 05 19:35:12 first of all, i said BUILD_CC, not CC Nov 05 19:35:19 err BUILD_CC I mean Nov 05 19:35:23 second, no need for export, bitbkae.conf handles all that Nov 05 19:35:27 just BUILD_CC = "gcc-4.7" Nov 05 19:35:28 should do Nov 05 19:35:31 alright, thanks Nov 05 19:35:34 but use itbake -e to exmaine it and make sure its set to that Nov 05 19:35:38 bitbake -e | grep BUILD_CC= Nov 05 19:35:50 bitbake -e autoconf-native | grep CC= Nov 05 19:41:37 ok, BUILD_CC shows up as gcc-4.7 Nov 05 19:41:44 thanks, that'll do Nov 05 19:42:03 make sure just 'CC' also shows up as that in a antive recipe, with the secon acommand above Nov 05 19:42:06 just to be safe Nov 05 19:42:27 np Nov 05 19:42:34 ah hm Nov 05 19:42:45 export CC="gcc" with autoconf-native Nov 05 19:43:08 I set BUILD_CC/CXX/CPP/CCLD to the 4.7 versions Nov 05 19:43:38 i was afraid that might happen, see how native.bbclass defines CC Nov 05 19:44:30 yeah. export CC = "${CCACHE}${HOST_PREFIX}gcc ${HOST_CC_ARCH}" Nov 05 19:45:05 * kergoth mutters Nov 05 19:45:05 you could try hacking around it with CC_class-native = "${BUILD_CC}", etc Nov 05 19:45:07 cross too Nov 05 19:45:21 well, I can always change the system's gcc symlink to gcc-4.7 , as unclean as it might be Nov 05 19:45:24 alternatively, cheat and add a subdir to PATH with a 'gcc' symlink :) Nov 05 19:45:43 if you use a separate subdir, at least you wouldn't be altering the system Nov 05 19:46:00 mkdir foo; ln -s $(which gcc-4.7) foo/gcc; PATH=$PWD/foo:$PATH; or whatnot Nov 05 19:46:04 btw. these problems show up with danny and ubuntu 13.10 Nov 05 19:46:05 * kergoth shrugs Nov 05 19:46:21 ahh, not too surprising. older release, newer distro Nov 05 19:46:22 I cannot build danny's gcc 4.7 with ubuntu saucy's gcc 4.8 (segfault) Nov 05 19:46:23 good to know Nov 05 19:46:48 ok, I will try that symlink trick Nov 05 21:18:22 khem, I need to go about actually creaing meta-sdr and pushing into the official OE repo Nov 05 21:18:55 what is the best way to see if I have commit access, and fixing that so I can't accidentally mess up "important" layers :) Nov 05 21:26:53 Crofton: do you mean adding it to meta-openembedded? Nov 05 21:27:27 yes Nov 05 21:27:58 a couple of jokers have been nagging me to add their stuff :) Nov 05 21:29:20 ok Nov 05 21:29:34 in that case you can create the layer without commit access (initially) just by sending a patch Nov 05 21:29:55 that's how most layers in meta-openembedded have been created Nov 05 21:30:31 annoyingly, I have some other crap in that branch :( Nov 05 21:30:56 well, creating branches is free in git :) Nov 05 21:32:52 and rebase -i is your friend :) Nov 05 21:35:26 as always :) **** ENDING LOGGING AT Wed Nov 06 02:59:58 2013