**** BEGIN LOGGING AT Tue Jan 14 03:00:00 2014 Jan 14 09:49:22 morning all Jan 14 09:49:49 hey bluelightning Jan 14 09:49:55 hi koen Jan 14 11:06:12 morning all Jan 14 11:06:59 hi pb_ Jan 14 11:12:08 hi bluelightning Jan 14 12:20:11 jackmitchell: do you know why cacao-initial has been kept at version 0.98, while cacao is 1.6.1? Jan 14 12:47:42 mario-goulart: I don't, woglinde is the man to ask when he's about, he comes in here sometimes Jan 14 12:48:02 I imagine something to do with compatibility between all the implementations Jan 14 12:48:13 I see. Thanks anyway, jackmitchell. Jan 14 16:22:33 Is it ok to include one machine.conf into another? Jan 14 16:22:37 yes Jan 14 16:22:40 thx Jan 14 16:24:05 will bitbake rebuild everything for the new machine if the only difference is some PREFERRED_PROVIDER settings? Jan 14 16:25:00 no, it shouldn't do Jan 14 16:25:30 thx again Jan 14 16:25:31 obviously it will rebuild everything that has PACKAGE_ARCH = "${MACHINE}" though Jan 14 16:31:50 related question, when appending to another recipe, is there any convention about keeping the same directory structure: meta-something/recipes-bsp/somerecipe/somerecipe_version.bb ==> meta-MINE/[everything else the same] ?? Jan 14 16:32:22 no, not particularly. you can do whatever makes things easier for you. Jan 14 16:32:29 ah Jan 14 16:33:09 there's a convention to put bbappends in the same structure as the recipe being appended, but even that's not that important :) Jan 14 16:33:15 and recipes are wherever you like Jan 14 16:33:58 kergoth: yeah, we don't follow that convention here; we flatten the hierarchy out a bit in our collection of bbappends, otherwise we end up with lots of very sparsely populated folders. Jan 14 16:34:38 * kergoth nods Jan 14 16:35:06 honestly I've always kind of disliked the recipes-* categorization, it's so arbitrary, and i always end up having to use find/ack/ag to find anything anyway :) Jan 14 16:35:15 right Jan 14 16:35:46 kergoth: so it's not just me who runs find N times a day :) Jan 14 16:37:38 If you haven't, check out ack (betterthangrep.com) and ag (http://geoff.greer.fm/2011/12/27/the-silver-searcher-better-than-ack/). save a great deal of time vs grep and find, since they only search particular file types and ignore scm metadata by default. https://github.com/sjl/friendly-find isn't bad either, though its syntax is a bit weird Jan 14 16:39:03 on a completely unrelated note, check out this little class i threw together yesterday — https://gist.github.com/kergoth/8410245 Jan 14 16:39:36 oooooh Jan 14 16:39:41 I've wanted that for a while Jan 14 16:39:52 saves me a lot of custom methods Jan 14 16:39:52 yeah, me too, turned out to be a bit easier than i thought it would be Jan 14 16:40:41 * kergoth would love to see the crazy number of default globally exported vars in bitbake.conf die in a fire, someday Jan 14 16:43:05 yeah, agreed Jan 14 16:48:34 Is there a way to say in a machine.conf, this machine can also be thought of as this other machine? Or do I need to add a bbappend for each recipe needing a COMPATIBLE_MACHINE line (not that there's many)? Jan 14 16:49:50 actually now that I look at it, it's just one recipe Jan 14 16:50:09 kergoth: would be interesting to try unexporting a few of them Jan 14 16:50:45 Jefro, the bot is running Jan 14 16:51:49 OE TSC/Workgroup meeting starts here in just under 10 mins, all welcome Jan 14 16:53:06 I won't be able attend all the time, but I'll keep an eye on the IRC window Jan 14 16:57:20 * otavio here Jan 14 17:00:58 * RP is here Jan 14 17:01:02 * bluelightning is here Jan 14 17:01:05 * JaMa is here Jan 14 17:01:17 here Jan 14 17:01:44 kergoth: are there any you find particularly annoying/problematic? I did try and cull a few a while back... Jan 14 17:01:49 almost here Jan 14 17:02:04 bluelightning, are you goin g to run the bot? Jan 14 17:02:18 #startmeeting Jan 14 17:02:19 Meeting started Tue Jan 14 17:02:18 2014 UTC. The chair is bluelightning. Information about MeetBot at http://wiki.debian.org/MeetBot. Jan 14 17:02:19 Useful Commands: #action #agreed #help #info #idea #link #topic. Jan 14 17:02:33 * fray is here.. Jan 14 17:02:34 #chair koen khem RP fray Jan 14 17:02:34 Current chairs: RP bluelightning fray khem koen Jan 14 17:02:35 don't forget to do the chair thing Jan 14 17:02:38 rofl Jan 14 17:02:41 heh Jan 14 17:02:51 bluelightning you wan tto continue the chair from the last meeting, or pick a "new" chair? Jan 14 17:03:12 I can continue I guess Jan 14 17:04:07 just searching for the info on last meeting Jan 14 17:04:38 * RP is finding things are a bit of a blur atm Jan 14 17:04:57 here's the mail I sent out today for reference Jan 14 17:04:59 http://lists.openembedded.org/pipermail/openembedded-core/2014-January/088294.html Jan 14 17:05:03 While bluelightning is doing that does anyone have any new agenda items? Jan 14 17:06:42 RP: do you want to cover OE-Core/release status first up, since we didn't cover that last time? Jan 14 17:06:54 #topic OE-Core / release status Jan 14 17:07:07 Sure Jan 14 17:07:29 We're coming to the end of the Yocto Project M2 milestone for 1.6 Jan 14 17:07:56 Basically pulling patches and getting M2 finalised and built Jan 14 17:08:46 I think we're keeping roughly up to date with patches but there are some subjects I'm just not finding enough quality time to do the right about of due diligence on (global uid/gid, git fetcher branch issue and bitbake -S issues) Jan 14 17:09:35 bug count is rising for OE-Core which is worrying, performance numbers are staying roughly neutral but there are patches being proposed which will impact them as things keep wanting to pull in perl for example Jan 14 17:09:56 another "pull request does not match patches sent to ml" issue popped up as well Jan 14 17:10:08 koen: link/reference? Jan 14 17:10:13 happy to answer any specific questions Jan 14 17:10:34 fwiw, I have one bitbake -S call running 5DAYS + 2 hours already (still doing something) Jan 14 17:10:57 koen, assuming it's the same as before.. sgw indicated he screwed up a merge and he'll be more careful next time Jan 14 17:11:04 bluelightning: yesterday "Antw.: [OE-core] [oe-commits] Upgrade Helper : base-passwd: upgrade to 3.5.29" Jan 14 17:11:08 if it's happened again, I don't tknow what to suggest Jan 14 17:11:33 JaMa: hah Jan 14 17:11:36 fray: it happended again Jan 14 17:12:27 JaMa: real work or locked in a loop? I have seen bitbake seemingly lock up at times. never found a good reproducer though :/ Jan 14 17:12:38 yeah, I fairly frequently have to kill wedged bitbakes Jan 14 17:12:57 pb_: any chance you can figure out what wedged? Jan 14 17:12:59 I saw a wedged bitbake this week as well on our autobuilders at linaro Jan 14 17:13:00 the wedged bitbake processes went away for me at the very end of the dora development Jan 14 17:13:16 I havn't done a lot of development with master recently (but do use it).. no problems there either Jan 14 17:13:41 I think the only time i hit them, personally, is when I ^c. i still have to pkill -f bitbake after an interruption at times Jan 14 17:13:52 RP: real work - as slowly showing more and more sigdata differences Jan 14 17:14:07 RP: yeah, I'll try to figure that out next time it happened. Jan 14 17:14:26 I pulled a new bitbake yesterday which I was (rather optimistically) hoping would have helped, but if anything the new version is worse Jan 14 17:14:26 JaMa: ok, I'll have to rethink what -S is doing Jan 14 17:14:54 pb_: I've tried to find this before but basically couldn't reproduce something reliably enough to debug it Jan 14 17:15:02 http://jenkins.nas-admin.org/job/oe_world_compare_signatures/11/console <- I don't know if it's visible to public without login Jan 14 17:15:39 RP: there's definitely a random element to it. it doesn't happen every time, but over the course of a few days we usually seem to accumulate a few jammed bitbakes that are just spinning at 100% cpu. Jan 14 17:15:48 JaMa: some profiling on those codepaths wouldn't be a bad idea either if people are hitting them frequently Jan 14 17:15:58 eventually they start consuming a big enough proportion of the total machine that I notice them. :-} Jan 14 17:16:22 pb_: right, I think the tasks do complete but there is something left hanging Jan 14 17:16:35 Can we focus on topic? debugging can be done after the meeting? Jan 14 17:16:47 yes, thanks otavio Jan 14 17:16:53 +1 Jan 14 17:17:04 any other questions on current status? Jan 14 17:17:35 RP: build failures Jan 14 17:17:52 otavio: what about them? Jan 14 17:17:58 otavio: which ones? Jan 14 17:18:13 RP: did it improve? when I returned from holidays I got a bunch of failures on meta-fsl-arm (which I fixed) Jan 14 17:18:28 RP: but generally, what is the status of other layers? Jan 14 17:18:51 otavio: of the things that the yocto autobuilder tests, master was pretty green before the last round of changes I put in Jan 14 17:19:04 * RP is awaiting the results of the next build Jan 14 17:19:16 otavio: I think piglit will add a new fsl-arm issue Jan 14 17:19:52 oh my Jan 14 17:19:54 lol Jan 14 17:19:58 Good Jan 14 17:20:42 The only ongoing failure I know about is the systemd qa test failures and ross is continue to look into that Jan 14 17:20:49 its proving hard to reproduce/track down Jan 14 17:20:54 Ok Jan 14 17:20:59 any other questions or should we move on? Jan 14 17:21:10 I'd say to move on Jan 14 17:21:13 I think we should probably move on Jan 14 17:21:27 #topic OE website/insfrastructure Jan 14 17:21:36 any infrastructure issues/concerns? Jan 14 17:22:00 the pieces of the infrastructure I use seem to be going well these days.. no extended outtages or lost mail to the lists.. Jan 14 17:22:01 I am not aware of any Jan 14 17:22:10 FYI, I haven't mentioned it here before but there is currently a problem with updating the layer index; Michael is working on it Jan 14 17:22:23 bluelightning: great Jan 14 17:22:31 layer index is still working though right? (was the other day when I tried it) Jan 14 17:22:39 you can still view it yes Jan 14 17:22:57 (basically the python version on the machine is too old for current bitbake, and the old bitbake we were using as a workaround no longer works with current metadata) Jan 14 17:23:22 Move on? Jan 14 17:23:32 bluelightning: time for buildtools-tarball? :) Jan 14 17:23:32 what about the new OE website redesign? Jan 14 17:23:45 discussion seems to have died down, but I'd love to see it.. Jan 14 17:23:49 kergoth: it's not that simple unfortunately, since django is involved... sigh Jan 14 17:23:50 maybe part of the jnaitorial day/week? Jan 14 17:24:04 I need to ping jackmitchell ka6sox and wmat Jan 14 17:24:11 bluelightning: do we have django recipes? :) Jan 14 17:24:22 RP: I think we do somewhere Jan 14 17:24:24 ah sorry guys, total absorbed in work I was meaning to be here Jan 14 17:24:46 RP: ultimately I think Michael's solution of just having a more modern distro is probably the better one Jan 14 17:24:56 we have django in meta-openstack :) http://layers.openembedded.org/layerindex/branch/master/recipes/?q=django Jan 14 17:25:02 re: new website design, I think me and ka6sox have been missing each other, but I'm ready to push something to a git repo somewhere Jan 14 17:25:16 bluelightning: agreed Jan 14 17:25:24 JaMa: ah right... I was thinking a bunch of the python recipes there would be ideal for meta-python (/offtopic) Jan 14 17:25:32 I just need a repo and permissions Jan 14 17:25:53 who provisions new repos on openembedded.org these days? Jan 14 17:26:12 probably ka6sox Jan 14 17:26:28 ka6sox can do it, I think I can too. Jan 14 17:26:40 bluelightning: I think I can create new repos as well Jan 14 17:27:04 ok, well ideally one of you needs to talk to jackmitchell and create the desired repo. ;) Jan 14 17:27:35 heh Jan 14 17:27:40 it needs to be available somewhere on the web too if possible Jan 14 17:27:53 ka6sox might be the best person to set up the other side of the connection to the website Jan 14 17:28:14 as I'm going to start a series of discussions on the text etc once we have a central point Jan 14 17:28:47 right, that's probably a ka6sox thing Jan 14 17:29:12 Crofton|work: Are you overall coordinating this? If so could you see if you could herd the cats? :) Jan 14 17:29:24 jackmitchell: what do you want as the name of the repo? Jan 14 17:29:27 can one of you add an action for me to get the website parties moving again? Jan 14 17:29:31 * jackmitchell meows at Crofton|work Jan 14 17:29:41 RP: don't mind Jan 14 17:29:50 RP: oe-site? Jan 14 17:29:52 Crofton|work -- part of the janitorial weekend as well (maybe?) Jan 14 17:30:29 fray: IMHO think we should probably concentrate on bugs for that weekend Jan 14 17:30:36 yep Jan 14 17:30:41 if you're talking about the upcoming bug weekend that is Jan 14 17:30:42 I think the WE will be extended hehehe Jan 14 17:30:43 are we changing topic? Jan 14 17:30:57 bluelightning ok.. I've not been involved with this stuff before -- so I'm not sure whats worked well in the past Jan 14 17:30:59 jackmitchell: do you have OE commit access ? Jan 14 17:31:01 Crofton|work: not really Jan 14 17:31:08 this is still website Jan 14 17:31:15 ok :) Jan 14 17:31:33 RP: I have a pub key that I sent to ka6sox some time ago, but I don't know where it was applied to Jan 14 17:32:23 ok I think we should probably move on Jan 14 17:32:33 jackmitchell: mail me a key and I'll setup the repo Jan 14 17:32:34 +1 Jan 14 17:32:43 JaMa: did you want to talk about world build failures? Jan 14 17:32:52 #topic world build failures / fixing Jan 14 17:33:19 we can shortly, the biggest problem is what to do with recipes which are failing for months Jan 14 17:33:53 in some cases I was moving them to non-working subdirs to remove them from world until someone steps up to maintain them Jan 14 17:33:56 reference: http://lists.openembedded.org/pipermail/openembedded-core/2014-January/088115.html Jan 14 17:34:06 and http://www.openembedded.org/wiki/Bitbake_World_Status Jan 14 17:34:18 ah yes, that's a better link Jan 14 17:34:28 JaMa: for oe-core ones, we could open bugs Jan 14 17:34:37 JaMa: I think I merged a fix for the make issue Jan 14 17:34:39 I did want to raise that Jan 14 17:35:11 JaMa, for oe-core -- they need to get fixed (or dropped)..bugs are the right way to raise that issue.. for other layers.. moving the stuff to an unmaintained and then removing it if not taken care of sounds like an excellent solution Jan 14 17:35:16 if you're getting any kind of failure or regression related to OE-Core, the best thing is to file a bug if none has already been filed Jan 14 17:35:29 RP: for "new" issues I'm usually trying to contact original author (if I still have the email in oe-commits folder) Jan 14 17:35:37 (and if a bug has been filed and it's being ignored, bring it up to one of the TSC folks..) Jan 14 17:35:42 JaMa: yes, its appreciated and does seem to be working Jan 14 17:35:44 JaMa: to be honest I think bugs are better; replies on the ML get lost Jan 14 17:36:05 if it doesn't work, the bug does get attention and does work for getting issues resolved Jan 14 17:36:06 JaMa: (thankyou for highlighting the issues though) Jan 14 17:36:50 * fray notes he agrees.. many month failures is a bad sign for OE.. and we need to deal with these.. (perhaps even the bugfix weekend is enough for some of these issues.. if we can hold them more often) Jan 14 17:37:02 some of those (e.g. monav failure) are caused by changes in oe-core and even with bug in bugzilla Jan 14 17:37:32 * Crofton|work is fixinf gnuradio after cmake changes ... Jan 14 17:37:43 YOCTO #5414 Jan 14 17:38:26 looks like it's being worked on 'slowly'.. but may need some help.. Jan 14 17:38:54 I think that one of the issues is that someone really needs to analyze what is causing those issues and it seems that nobody really care/does that Jan 14 17:38:58 https://bugzilla.yoctoproject.org/show_bug.cgi?id=5414 Jan 14 17:39:12 I'm not sure it's that nobody cares.. but I don't think many people have experience w/ QT.. Jan 14 17:39:33 I wasn't talking about this one now, sorry Jan 14 17:39:34 I'd love to see actual QT maintainers take an active role in this (people working for whoever owns QT these days) Jan 14 17:39:58 but in general freenode upgrade breaks 5 recipes and cmake detection is still broken in oe-core Jan 14 17:39:59 fray: that would be Digia Jan 14 17:40:17 but AB build cannot detect it because it builds on rather small subset of layers Jan 14 17:40:18 fray: I don't think qt-mobility is maintained anymore to be honest Jan 14 17:40:24 could be wrong Jan 14 17:40:27 no idea Jan 14 17:40:48 JaMa, I do think we need more AB runs with other subsets of functionality.. but I'm not sure I know the "right" sets to focus on Jan 14 17:40:57 as most of you are aware, i'm trying to work on a mini side project to determine which layers are maintained :-) Jan 14 17:41:15 (from personal experience, I've limited the layers I work with to ones I maintain and sets my customers need.. but that doesn't cover some of the other general cases) Jan 14 17:41:27 tlwoerner ya, that is definitely going to help Jan 14 17:41:37 The Yocto Project agreed to step up and work closely on the core which is what it tries to do. Testing many other layers was and still is out of scope of the Yocto Project resources Jan 14 17:41:43 if nothing else, layers that don't build and/or are unmaintained should me either marked as such, or removed Jan 14 17:41:49 Equally, people do try and help where they can Jan 14 17:41:58 meta-java is one of layers which we have most commonly having issues at OS. From time to time mario-goulart ends needing getting build failures Jan 14 17:42:19 * mario-goulart confirms that :-) Jan 14 17:42:30 hmm woglinde isn't around atm Jan 14 17:43:14 tlwoerner: worth mentioning, the layer index does already provide a "layer note" functionality - we can add notes that show up prominently on the layer page Jan 14 17:43:15 ok, I think we can move on.. Jan 14 17:43:23 right Jan 14 17:43:26 bluelightning: sounds great Jan 14 17:43:28 horse is dead Jan 14 17:43:39 bluelightning: can anyone add notes? Jan 14 17:44:03 tlwoerner: it's restricted to the layer maintainers and a set of admins (including the TSC) Jan 14 17:44:27 okay, i'll just update the mailing list with my results and keep track Jan 14 17:44:42 i'd like to talk about bugzilla maintenance and the bug fixing weekend (?) Jan 14 17:44:53 sure Jan 14 17:45:02 #topic bug fixing weekend Jan 14 17:45:13 some projects automatically discard older bugzilla entries Jan 14 17:45:19 and/or entries that haven't had any updates Jan 14 17:45:48 would it be worthwhile if i went through the list and identified bugs that are no longer useful? Jan 14 17:46:00 so, luckily for us I don't think we've reached the point where we just have too many bugs to individually triage Jan 14 17:46:11 we do do a reasonable job at triaging bugs as they come in Jan 14 17:46:25 The bugzilla is pretty up to date in terms of triage of bugs like that Jan 14 17:46:26 we're just short of people to actually investigate and fix the issues Jan 14 17:46:53 okay, Jan 14 17:47:00 however, one slight exception is that we do have quite a number of bugs in NEEDINFO state; some of these could probably be closed with a comment asking to reopen if the issue persists Jan 14 17:47:01 If anyone does spot problematic bugs, mentioning them to me/bluelightning would allow us to escalate them Jan 14 17:47:03 a nice list of bugs people think should be worked on, and the bugs people ARE working on would be nice.. Jan 14 17:47:07 i'm just wondering about really old bugs, like https://bugzilla.yoctoproject.org/show_bug.cgi?id=270 for example Jan 14 17:47:13 it's from 2010 Jan 14 17:47:15 (those in NEEDINFO that haven't been responded to by the original poster) Jan 14 17:47:16 I know I've got a couple of enhancements I'm going to try to find time from Jan 14 17:47:46 270 is still valid.. but it's REALLY low priority.. Jan 14 17:47:51 tlwoerner: well, that's an enhancement Jan 14 17:47:58 if i identify bugs that are over a certain age, in NEEDINFO, haven't been updated, can't be reproduced... Jan 14 17:48:10 tlwoerner: the ones of more concern (IMHO) are bugs rather than enhancements Jan 14 17:48:23 * fray wants to find time for bug 1238 BTW :) Jan 14 17:48:24 bluelightning: okay, bad example :-) Jan 14 17:48:46 there are definitely old entries Jan 14 17:49:00 I saw a number of emails about schedule, did we come to a conclusion? Jan 14 17:49:11 NEEDINFO bugs may be looked at, but I wouldn't expect to be a priority.. Jan 14 17:49:19 possibly even ones where we could make a judgement and say we're never going to fix; I guess we have erred on the side of setting it to future if there's a chance someone will come along and implement/fix it Jan 14 17:49:31 yup Jan 14 17:49:59 Crofton|work: IIRC the date was proposed but not widely agreed to, so we just need to do that Jan 14 17:50:16 I want to lobby for one week day :) Jan 14 17:50:23 #action all reply to Trevor's bug thread Jan 14 17:50:30 list trffic drops a lot over weekend these days Jan 14 17:50:30 Crofton|work: with regard to my emails... Jan 14 17:50:36 i think we've decided a 4day weekend shoudl be used Jan 14 17:51:04 Crofton|work: in that case you can pick either the friday or the monday of the 4-day weekend :-) Jan 14 17:51:06 I agree with 4 days weekend work. Jan 14 17:51:07 reportedly that worked when OE used that a long time ago Jan 14 17:51:14 so I'm in favour Jan 14 17:51:19 k Jan 14 17:51:24 i'm trying to get a feel for how soon Jan 14 17:51:32 if i say "this weekend" everyone is already busy Jan 14 17:51:48 yeah that's probably a bit early Jan 14 17:51:57 Crofton|work: any word from the Yocto Advisory Board? Jan 14 17:52:03 This weekend is the best for me personally to try to help out.. Jan 14 17:52:08 not sure if there was a meeting since last TSC meeting Jan 14 17:52:10 if i say "a month from now" nobody will remember and schedule it in Jan 14 17:52:11 suggestions? Jan 14 17:52:11 I'd liek something concrete to say Jan 14 17:52:31 like tehre will be a bug squashing persid from blah to blah, please encourage peopel to attend Jan 14 17:52:31 Crofton|work: as in a date? Jan 14 17:52:34 yeah Jan 14 17:52:40 period Jan 14 17:52:48 ok Jan 14 17:53:05 we should also make sure we can track some metrics Jan 14 17:53:11 so jefro can blog about resutls :) Jan 14 17:53:40 fray: probably too soon to get lots of people involved Jan 14 17:53:42 Crofton|work: sounds good; I think we can pull out stats of bug activity fairly easily these days Jan 14 17:53:50 how about the weekend starting jan 31st? Jan 14 17:54:14 i.e. 2 weeks from now (roughly) Jan 14 17:54:19 only problem there is that's the FOSDEM weekend Jan 14 17:54:21 tlwoerner yup.. :( Jan 14 17:54:24 :) Jan 14 17:54:40 I and a few other OE folks will be going to FOSDEM so we wouldn't be around then Jan 14 17:54:54 this is one reason I suggested a one day event Jan 14 17:54:57 to get us started Jan 14 17:55:12 bluelightning: :-) yes, i should have checked... Jan 14 17:55:23 moin Jan 14 17:55:54 anyone else have suggestions? Jan 14 17:56:09 time check: 4 mins FYI Jan 14 17:56:13 pick one day and have a trail event Jan 14 17:56:16 trail Jan 14 17:56:18 trial Jan 14 17:56:37 let's just try 1 month from now, i.e. 2 weeks after fosdem. Jan 14 17:56:41 What about do a trial this weekend and another in feburary? Jan 14 17:57:01 well, if we're going to trial it I would have thought we'd trial it in the manner we intend to do it i.e. over a weekend Jan 14 17:57:16 bluelightning: although... that might be a good time to hold it :-) Jan 14 17:57:16 organize a "hacking room" Jan 14 17:57:27 bluelightning: right Jan 14 17:57:31 So we'd have 8 days of bugfixing and would us to use this WE to make some fuzz about it Jan 14 17:57:33 otavio: fray said that would work for him ; anyone else? Jan 14 17:57:59 otavio: 8 days? Jan 14 17:58:05 now and in Feb Jan 14 17:58:10 tlwoerner: there are quite a lot of other distractions at FOSDEM. of course, back in the day, we used to have oe developers' meetings for that. Jan 14 17:58:15 s/that/hacking time/ Jan 14 17:58:18 * tlwoerner can find time this weekend Jan 14 17:58:41 I want to be involved.. but don't plan around my schedule.. :) Jan 14 17:58:58 but it's likely to just pick a date.. run the thing for whoever can do it.. and then keep doing that.. Jan 14 17:59:05 some days you'll have 3 helpers others 30.. Jan 14 17:59:18 agreed Jan 14 17:59:26 fray: yes, i think we need more "experience" at running them to see what works and what doesn't (experimentation) Jan 14 17:59:32 right, shall we try it this weekend then? Jan 14 17:59:39 (1 min to go) Jan 14 17:59:42 +1 Jan 14 17:59:46 +1 Jan 14 17:59:46 thiw weekend is fine with me Jan 14 17:59:49 there's always a concern they might become so common nobody attends Jan 14 18:00:07 okay, we'll set up a trial for this weekend Jan 14 18:00:09 lets try this weekend then, see how it goes.. tentatively schedule a weekend next month.. Jan 14 18:00:14 I'm ok with that Jan 14 18:00:15 and do so for say 3-4 months.. Jan 14 18:00:17 :-) Jan 14 18:00:25 awesome Jan 14 18:00:26 and we'll see what kind of attendance we can get and if it's still worthwhile or not Jan 14 18:00:38 tlwoerner: would you mind doing the announcement ? Jan 14 18:00:46 Crofton|work: can you send something to the AB (acknowledging its short notice) Jan 14 18:00:55 who would i talk to about setting up a sign-up sheet on the wiki? Jan 14 18:00:56 We could like to it one mounth before Yocto release (so twice a year) Jan 14 18:00:58 I'm concerned about a edmogrphic shift from weekends to weekdays Jan 14 18:01:01 I will Jan 14 18:01:08 tlwoerner: if you need help I'd be happy to Jan 14 18:01:11 (with the wiki) Jan 14 18:01:11 or should i do that through email? Jan 14 18:01:11 (on the mailing list) Jan 14 18:01:27 sned an announcement via email Jan 14 18:01:35 I will forward to YAB with some cover Jan 14 18:01:50 we'll be coordinating in this channel I suspect Jan 14 18:01:54 during the weekend itself Jan 14 18:02:07 ok folks, we're over time, thanks everyone Jan 14 18:02:18 #endmeeting Jan 14 18:02:18 Meeting ended Tue Jan 14 18:02:18 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) Jan 14 18:02:18 Minutes: oe/2014/oe.2014-01-14-17.02.html Jan 14 18:02:18 Minutes (text): oe/2014/oe.2014-01-14-17.02.txt Jan 14 18:02:18 Log: oe/2014/oe.2014-01-14-17.02.log.html Jan 14 18:02:27 bluelightning: yes, i'll do the announcement and organize Jan 14 18:02:31 tlwoerner: thanks Jan 14 18:02:39 much appreciated Jan 14 18:02:58 tlwoerner: thanks! Jan 14 18:03:52 i'm off to other stuff now, but it'll be out by my (EST) end of day today Jan 14 18:08:30 we didn't even get to LAVA :( Jan 14 18:08:56 no Jan 14 18:09:27 is lava not something that we can just discuss on the mailing list anyway? Jan 14 18:09:50 we can yes Jan 14 18:10:08 in fact, there is an additional mailing list being set up for automated hw testing Jan 14 18:10:18 sure Jan 14 18:10:24 what is this new mailing list? Jan 14 18:10:35 (this allows folks like the upstream LAVA developers to participate without being bombarded with all the usual traffic) Jan 14 18:10:48 btw, we can submit jobs to the community instance Jan 14 18:10:54 tyler can make you an account Jan 14 18:11:08 ndec: so it may be still in the process of being set up, but I think this is it: https://lists.yoctoproject.org/listinfo/automated-testing Jan 14 18:11:13 Are you guys talking to the Codethink guys about that sort of testing (mainly Kinnison and liw - I know the LAVA guys are) Jan 14 18:11:30 broonie: we haven't been talking to them specifically no Jan 14 18:11:46 broonie: we did open discussions with Tyler & Allen on the LAVA team though Jan 14 18:12:02 bluelightning: thanks, subscribing.. i didn't know about that list. was it announced (i could have missed it..) Jan 14 18:12:11 bluelightning: OK, this is totally separate to LAVA but they were talking about stuff around full system testing. Jan 14 18:12:24 Possibly including use of LAVA at some point. Jan 14 18:12:56 ndec: it hasn't been yet; you are more than welcome to join it though (as is anyone else) Jan 14 18:13:11 ;-) Jan 14 18:13:18 I am a LAVA expert now: http://community.validation.linaro.org/scheduler/job/4502 Jan 14 18:13:23 ndec: it's brand new, you can see there aren't even archives :) Jan 14 18:13:46 indeed! Jan 14 18:14:01 Crofton|work: congrats. Jan 14 18:14:13 the interesting thing is it can fetch the bits via http Jan 14 18:14:14 http://community.validation.linaro.org/scheduler/job/4502/definition Jan 14 18:14:38 so I could put my output on dropbox and submit for testing (as an example) Jan 14 18:14:39 well, what would you expect? fetch from bzr only ;-) Jan 14 18:15:37 heh Jan 14 18:17:21 one more idea for world build issues, would it make sense to revive classes/oestats-client.bbclass from oe-classic and have one global database to at least see some usage statistics? Jan 14 18:18:20 JaMa: I'm not sure I'm familiar with that (other than the name) - was it just for failures or all builds? Jan 14 18:19:38 both and even sending list of qa issues it seems Jan 14 18:20:45 I don't know how much traffic it was generating or how big the db was, but it was nice when something failed for me locally to just query the database and see if it's now failing for everybody or just me Jan 14 18:21:47 and before removing some recipe as unmaintained from meta-oe I would be able to ping people building it successfully (e.g. for some other platform) that it will be removed unless they step-up and volunteer to fix it e.g. for qemux86-64 Jan 14 18:21:47 oestats was pretty interesting Jan 14 18:23:22 I have: Jan 14 18:23:23 INITSCRIPT_NAME = "wpa_supplicant" Jan 14 18:23:23 INITSCRIPT_PARAMS = "start 06 5 2 3 . stop 21 0 1 6 ." Jan 14 18:23:23 inherit update-rc.d Jan 14 18:23:38 but I don't get the links created, anything comes to mind ? Jan 14 18:24:26 checked the do_rootfs log? Jan 14 18:28:43 * kergoth ponders Jan 14 18:29:31 yeah, nothing there Jan 14 18:30:01 shoud a try a cleansstate of my image ? Jan 14 18:33:47 abelloni: did you install the package in the image? Jan 14 18:35:02 ndec: yeah, my binary is there Jan 14 18:35:11 the init.d script is there too Jan 14 18:35:31 I did that in a .bbappend but I don't think it is relevant Jan 14 18:35:47 http://code.bulix.org/8bx3x2-85439 Jan 14 18:37:51 hmm. that looks ok. Jan 14 18:39:22 yeah, exactly what I am thinking :) Jan 14 18:43:22 I'm trying a cleansstate on my image, I'll tell you Jan 14 19:28:40 Is there any kind of simply flow chart (in text, even) of config file priority? For my specific example (of the moment), I added a machine to SANITY_TESTED_DISTROS in my build/conf/local.conf file, but I'd like to add it somewhere that is checked in. I'm not really sure where that would be. I've also had this problem when trying to figure out where to modify variables that affect an image like PREFERRED_PROVIDER. Jan 14 19:29:53 see the top of bitbake -e Jan 14 19:29:59 it shows what config files were parsed in what order Jan 14 19:30:09 thx! Jan 14 19:30:13 fundamentally, config wise, after bblayers processing, bitbake only parses one file: conf/bitbake.conf Jan 14 19:30:19 bitbake.conf includes everything else, including local.conf Jan 14 19:30:27 so reading poky/meta/conf/bitbake.conf should be informative Jan 14 19:33:32 I'm looking over the -e list now and will checkout bitbake.conf. Jan 14 19:38:41 * pb_ stabs prelink Jan 14 19:39:47 * JaMa holds prelink Jan 14 19:40:04 heh Jan 14 19:40:38 JaMa: is it actually doing anything useful for you at the moment? right now it seems to be so broken on arm that it isn't actually managing to prelink any useful quantity of my binaries. Jan 14 19:41:00 admittedly it does seem to be a little bit less busted on mips. Jan 14 19:42:13 * kergoth makes a list of improvements he'd like to see in oe/yocto, but which are unlikely to go into oe-core due to compatibility, and wonders how hard it'd be to try a new more basic oe-core replacement, or a fork, to play with such things until/if they can go in Jan 14 19:42:41 that would be interesting, yes Jan 14 19:43:18 pb_: the number of binaries which fail to prelink isn't so bad in our images, but I don't know who enable it in our build or how much useful it currently is Jan 14 19:43:29 kergoth: Is it "wrong" to put local.conf changes inside my meta-MINE/conf/layer.conf? Jan 14 19:43:41 sr105: its so wrong i hardly know where to begin. Jan 14 19:43:49 sr105: only one of any given config file is loaded, not all of them Jan 14 19:44:03 so you'd make it impossible for the user to use local.conf in theri build directory, or it wouldn't be used at all, depending on BBPATH ordering Jan 14 19:44:35 pb_: relocation in .text are the most common reason for failing to prelink in our image Jan 14 19:44:35 sr105: I'd suggest taking a step back and considering what exactly you want to achieve, before you dive into where/how you want it done. what's the goal here Jan 14 19:44:37 but looking at the list, only the files in build/conf and the various layer.conf files are available Jan 14 19:45:06 changing config when a layer is included in bblayers in general is extremely bad. layers shouldn't change policy unless the user opts into that Jan 14 19:45:07 sr105: did you mean literally ship a local.conf inside your layer, or did you mean put the stuff that would usually go in local.conf in your layer.conf instead? Jan 14 19:45:11 I just wanted to save SANITY_TESTED_DISTROS += "LinuxMint-15" somewhere where it will be used and can be checked in to source control Jan 14 19:45:23 pb_: the latter Jan 14 19:45:26 then i'd suggest you provide your own distro, which pulls from poky Jan 14 19:45:31 or not, whichever Jan 14 19:45:49 but a distro is the most appropriate place for such things, as the distro is what defines policy, and what distros are supported is policy Jan 14 19:45:54 sr105: well, it'd work. it's not very wholesome, but if nobody other than you will use the layer then it isn't so awful. Jan 14 19:45:59 kergoth: that's why I asked, because it felt *really* wrong Jan 14 19:46:27 I'll look into extending the distro Jan 14 19:46:28 generally, you'd have a distro layer for that, like kergoth says. or if it's site-local configuration, put it in site.conf Jan 14 19:48:02 SANITY_TESTED_DISTROS isn't exactly distro policy either though. I don't really know offhand where the "right" place for that would be. Jan 14 19:48:19 in a sense, each layer ought really to be declaring what distros it thinks it's happy with, and oe should be taking the intersection of all of them. Jan 14 19:48:44 I'm sure we'll be modifying the distro eventually for customizations, so it won't be a wasted exercise. Jan 14 19:49:01 I'd think the implication of SANITY_TESTED_DISTROS is that you've done actual builds on those distros, and will fix any brokenness that appears when doing builds there Jan 14 19:49:18 so if you think about it like that, i think distro can make sense, since a distro usually does do a certain amount of support for its users Jan 14 19:49:25 but it depends on how you think about it Jan 14 19:49:37 sr105: indeed Jan 14 19:51:38 thanks for the help and suggestions Jan 14 20:20:55 does someone got the cardhu-nvidia-tegra3-xorg drivers working ? Jan 14 21:01:38 i occasionally get such kind of errors 'ExpansionError: Failure expanding variable SUMMARY, expression was ${SUMMARY} - Debugging files which triggered exception Exception: variable SUMMARY references itself!' generally wiping tmp/ just 'solves' this issue. this is when parsing a packagegroup recipe where DESCRIPTION is set, not SUMMARY, and it's on dylan. Jan 14 21:07:47 Is there an easy way to install an updated rpm into the rootfs on my sdcard without re-creating the rootfs and redoing the whole thing? Jan 14 21:09:16 http://www.cyberciti.biz/tips/how-to-extract-an-rpm-package-without-installing-it.html Jan 14 21:11:12 tastycactus: you can chroot into the root fs assuming you have package management tools in the image. Jan 14 21:12:49 pwgen, ndec: thanks Jan 14 21:13:30 Alternatively, can I do something like DESTDIR=/media/rootfs bitbake -c install packagename ? Jan 14 21:13:46 no. Jan 14 21:14:03 'install' is not the 'install into root FS' that you might think. Jan 14 21:14:56 each recipe produces 'packages' which do into tmp/deploy/rpm, then during the image recipe which is a 'special' recipe, all packages are extracted into the rootfs Jan 14 21:16:29 it should be possible to figure out the exact command that deploys a rpm into the image rootfs, but then you would need to recreate the images from the updated rootfs. and it could be a source of errors as well. Jan 14 21:22:27 ndec: I've seen that summary thing before, iirc it happens if it gets expnaded at hte wrong time Jan 14 21:22:38 the sub-package vars reference the main vars, yet the packaging code uses those overrides Jan 14 21:22:53 hmm. right, it seems to be in do_deploy_ipk in my case. Jan 14 21:22:59 that is, SUMMARY_${PN}-dev references ${SUMMARY}, and the packaging code occasionally adds to Overrides, which collapses it into SUMMARY Jan 14 21:23:13 we need ot fix the packaging code to explicitly check th esub-package variable versions, if any are still using overrides for it Jan 14 21:23:15 iirc anyway Jan 14 21:23:42 right, that's exactly what I just realized. Jan 14 21:23:45 we used to have workaround code which forced an early expansion of those vars, so at packaging time ${SUMMARY} had already been expanded Jan 14 21:24:02 by injecting a new packagefunc Jan 14 21:24:02 (in emta-mentor) Jan 14 21:24:02 meta-mentor Jan 14 21:24:02 but for some reason we don't hit it anymore :) Jan 14 21:24:22 we do this: summary = localdata.getVar('SUMMARY', True) in do_package_ipk when we might not be processing the main package, but a sub package Jan 14 21:24:44 i guess if you set SUMMARY, you don't hit the problem Jan 14 21:24:50 right. it should stop mangling overrides and running finalize/update_data, and just getVar('SUMMARY_' + pkg, True) or getVar('SUMMARY', True) Jan 14 21:24:51 set in the recipe, that is. Jan 14 21:26:14 the packaging code could use some cleanup and refactoring all around, really :) Jan 14 21:28:51 kergoth: do you think there is a bug for that already? Jan 14 21:28:59 hmm, not sure honestly Jan 14 21:29:02 not the refactoring.. but that specific var expansion. Jan 14 21:29:16 since we havne't hit it in some time, it hasn't been a priority for us. not sure if anyone else opened one Jan 14 21:29:43 kergoth: i tested this change Jan 14 21:29:43 - summary = localdata.getVar('SUMMARY', True) or localdata.getVar('DESCRIPTION', True) or "." Jan 14 21:29:43 + summary = localdata.getVar('SUMMARY_' + pkg, True) or localdata.getVar('DESCRIPTION', True) or "." Jan 14 21:30:01 now i get past SUMMARY, but it fails for DESCRIPTION.. Jan 14 21:30:06 that should fall back from SUMMARY_pkg to SUMMARY and then to DESCRIPTION Jan 14 21:30:10 and yeah, description does the same thing Jan 14 21:31:46 https://github.com/MentorEmbedded/meta-mentor/blob/c49f815702c3537bd10cbdecee04838ea8364209/classes/package_early_expand.bbclass was our hack Jan 14 21:31:51 (definite hack :) Jan 14 21:32:33 hmm. ok. however I don't understand what the original code is expected to produce. Jan 14 21:33:00 since SUMMARY is set, localdata.getVar(SUMMARY) will always return the content of SUMMARY, right? Jan 14 21:34:05 btw, bitbake -e xxx | grep ^SUMMARY returns the right thing. Jan 14 21:39:24 I've seen that SUMMARY failure once as well, though only once. Jan 14 21:40:19 I don't quite know why it seems to come and go randomly. I guess the non-determinism must be a bitbake bug somewhere. Jan 14 21:40:21 is it right that if we set SUMMARY *or* DESCRIPTION in the recipe, it's 'better' to set SUMMARY than DESCRIPTION? Jan 14 21:40:57 yes, that's the theory Jan 14 21:41:07 if you set only SUMMARY then DESCRIPTION will inherit that value. Jan 14 21:41:22 if you set only DESCRIPTION then you get the bitbake.conf default SUMMARY which is, frankly, useless. Jan 14 21:41:32 hmm. ok. i think I will do that for now... i don't understand well enough the variable parsing to do anything better... Jan 14 21:41:56 the 'SUMMARY' issues I am seeing is when only DESCRIPTION is set. Jan 14 21:42:09 if i set SUMMARY instead, it goes away Jan 14 21:42:21 right Jan 14 21:42:28 it'd be worth posting to the list, and/or filing a bug for that Jan 14 21:45:46 * pb_ stabs bzip2-native Jan 15 02:59:09 I got: Jan 15 02:59:12 ERROR: Function failed: Fetcher failure for URL: 'http://www.makotemplates.org/downloads/Mako-0.7.2.tar.gz'. Unable to fetch URL from any source. Jan 15 02:59:15 known? **** ENDING LOGGING AT Wed Jan 15 02:59:59 2014