**** BEGIN LOGGING AT Tue Nov 11 03:00:00 2014 Nov 11 08:53:12 good morning Nov 11 09:23:10 morning mckoan Nov 11 09:26:42 morning mago_ Nov 11 09:26:46 morning all Nov 11 09:26:50 morning mckoan Nov 11 09:27:14 hey! Nov 11 09:30:12 bluelightning: on my way to work this morning i thought about how cool it would be to use bitbake for a non-linux project. Is there any ongoing effort to create a layer that only holds the toolchain (not including libc-version), native tools etc? i guess meta-oe-core could be based on this later Nov 11 09:30:47 mago_: I don't know of any project like that, but it does sound interesting Nov 11 09:30:54 might be worth posting an RFC on the mailing list Nov 11 09:38:33 mago_: are you Ulf? Nov 11 09:39:11 alright. not sure how you'd make the split though, because there are quite a lot of OS-dependencies in toolchains etc Nov 11 09:39:27 mckoan: Ulf? No :) Don't know any Ulf Nov 11 09:40:13 mago_: Ulf is emagii Nov 11 09:40:36 okay Nov 11 09:40:49 argh, that was meant for mckoan Nov 11 09:40:52 stupid tab Nov 11 09:40:54 anyway... Nov 11 09:41:02 i guess you all work at the same company, or something Nov 11 10:14:59 koen: aha, catch it Nov 11 12:16:09 Hi, i wanted to remove some packages which are not used in bb files. RDEPENDS is used for including these packages. I wanted to remove it in bbappend. How can i remove it? I tried RDEPENDS_* -= "" . But is not helping. Nov 11 12:32:59 RDEPENDS_* = Nov 11 12:33:02 uhm Nov 11 12:33:11 RDEPENDS_nameofpackage = Nov 11 12:33:21 should reset the included files Nov 11 16:44:18 just a reminder, the public OE TSC/workgroup meeting will be happening in here in about 15 minutes, all welcome to participate Nov 11 16:46:12 WASSUP Nov 11 16:46:29 * rburton realises he's just dated himself quite accurately Nov 11 16:47:56 bluelightning: ok, thx Nov 11 16:53:38 hey mckoan sad to hear you have a smelly power block Nov 11 16:54:22 magic smoke about to be let out? Nov 11 16:54:44 Crofton|work: no prob, my main concern was that all could be the same Nov 11 16:54:56 yeah, I understand Nov 11 16:55:14 not good for the project if we hand out defective swag :) Nov 11 16:55:24 bluelightning: i'm concerned that "power block" is slang for something unsavoury Nov 11 16:55:39 Crofton|work: I have the second one in charge since this morning and is ok Nov 11 16:55:49 that is good news Nov 11 16:59:24 fray / RP / khem / koen - are you guys here? Nov 11 16:59:25 Crofton|work: just attached the power bank to my mobile Nov 11 16:59:35 Crofton|work: it smokes !!! Nov 11 16:59:52 intriguing Nov 11 17:00:00 I thought indoor smoking was banned in the EU Nov 11 17:00:11 Crofton|work: Nexus4 is not Yocto compatible :-D Nov 11 17:00:15 can you post a video> Nov 11 17:00:18 rofl Nov 11 17:00:42 Hi TSC Nov 11 17:00:42 I wonder if we have left over ones? Nov 11 17:00:47 * RP is here Nov 11 17:00:48 ok, let's start the meeting Nov 11 17:01:00 evening all Nov 11 17:01:17 hi JaMa, jackmitchell Nov 11 17:01:22 I'm here now.. :) Nov 11 17:01:27 hi fray Nov 11 17:02:19 let's wait a minute or two to see if anyone else joins in Nov 11 17:02:44 Hi all, I'm here Nov 11 17:03:01 hey paulbarker Nov 11 17:03:55 * nerdboy lurks for a bit Nov 11 17:03:57 paulbarker: for what its worth i couldn't replicate the opkg failure on my own machine, but the ab did it reliably Nov 11 17:04:02 Peter Bigot coming in late without saying anything.... Nov 11 17:04:07 hi nerdboy, pabigot Nov 11 17:04:11 so, does anyone else particularly want to chair this time? Nov 11 17:04:29 rburton: Thanks, I'm going to give it a build shortly. Been busy so far today. Nov 11 17:05:05 saw eric idle last night and all i have is a python response... Nov 11 17:05:25 I guess I will do it then :) Nov 11 17:05:41 * nerdboy hacking python sensor code so it's all good Nov 11 17:06:17 I don't have an agenda written out but let's start with anything noteworthy on where we are with master / the current development cycle - RP? Nov 11 17:06:56 Hi all, just watching! Nov 11 17:07:51 dizzy is the new stable branch, master is open for new work and patches are being merged now Nov 11 17:08:30 the patch backlog for master isn't massively backlogged now so if there's anything important that isn't merged feel free to ping Nov 11 17:08:31 Power64 and aarch64 work is being stagged for master as well.. Nov 11 17:08:42 (qemu bsps for each).. Nov 11 17:09:21 sorry, getting distracted :( Nov 11 17:09:31 basically master is back open for business Nov 11 17:09:51 I think we've dealt with most of the queue but we are having challenges getting the patches merged Nov 11 17:10:04 what kind of challenges? Nov 11 17:10:17 I did want to echo what I said in an email yesterday - procps upstream looks dead and most distros have moved to procps-ng. We should probably do the same this cycle Nov 11 17:10:29 Crofton|work: some patches trigger failures when we test them on the autobuilders and we then struggle to explain/debug/fix those failures Nov 11 17:10:34 paulbarker: that sounds good to me FWIW Nov 11 17:10:49 paulbarker, I believe you are correct on that.. but I haven't looked at license issues or anything else to see if that's going to create any problems Nov 11 17:10:51 paulbarker: sounds good to me too Nov 11 17:11:37 I'll have a look at the license then. Unsure if I'll have time to do the whole change myself as we hold a few patches against procps, but I can at least check licensing Nov 11 17:11:50 rburton: few patches for REQUIRED_DISTRO_FEATURES in xorg recipes, RP replied it's in queue, but I haven't seen it anywhere Nov 11 17:12:01 rburton: should I resend them? Nov 11 17:12:11 as long as the new stuff isn't GPLv3 we should be able to do a replacement.. if it's GPLv3.. then we'll have to keep the 'last' version of hte old code.. Nov 11 17:12:21 JaMa: ping the thread, they'll still in my inbox at least Nov 11 17:12:22 (we can still put int he procps-ng and I think we should) Nov 11 17:12:47 JaMa: I said please send, I'm not aware of them in a queue Nov 11 17:13:32 COPYING contains GPLv2, should be good Nov 11 17:13:34 one thing I'd like to throw in.. there (especially for new users) has been some confusion during the "freeze" cycle at the end of the dizzy release.. people were sending patches and they were not going in.. Nov 11 17:13:58 fray: any suggestions on how we communicate freeze dates / status better? Nov 11 17:14:01 We need to come up with a better way to advertise the freeze cycle for new users so they understand patches are delayed due to a pending release.. but they will still go in.. Nov 11 17:14:22 RP: ah, you were replying on them :) so I thought you mean those patches I've sent Nov 11 17:14:23 unfortunately I don't have any suggestions on how to improve this.. but it's something we need to do.. Nov 11 17:14:40 I think during the freeze especially it would be good to let people know the patches are being held back but have been seen Nov 11 17:14:49 once master is "reopened", it's also easy to miss a few things.. so it's important that the submitters followup if possible.. Nov 11 17:14:52 patch tracking overall seems to be an area of continuing misunderstanding Nov 11 17:15:11 I think rburton was replying to each one towards the end... Nov 11 17:15:34 Crofton|work: right... rburton did you get anywhere with the OE-Core patchwork? Nov 11 17:15:35 I know I'm somewhat wondering if she follow Linus's lead.. during a freeze period.. patches are ignored.. (I think thats a bit draconian) but it did get the message across to submitters to wait until the tree was open again Nov 11 17:15:38 * JaMa would say "gerrit", but don't want to make RP angry again Nov 11 17:16:02 * fray has not yet found a patch system he's "happy with".. some are less bad then others.. :P Nov 11 17:16:18 I'm still convinced patchwork can be made to work Nov 11 17:16:20 JaMa: I once again tried to use it recently and I hate it with a passion :( Nov 11 17:16:42 bluelightning: not really, got busy with other things Nov 11 17:17:04 bluelightning: unfortunately contributors (often also maintainers) aren't updating status in patchwork Nov 11 17:17:21 JaMa: the thing is they shouldn't have to, that's part of what needs addressing Nov 11 17:17:21 bluelightning: and updated pull-request branch in some remote repo isn't shown in patchwork Nov 11 17:17:51 as much as possible status updates should be automatic, so you can look at patchwork and have a reasonable expectation that it's showing the real status Nov 11 17:17:55 bluelightning: so if I don't update the patches in master-next immedietaly after I notice e-mail saying that pull branch was updated, I'll probably forget it Nov 11 17:18:03 * Crofton|work doesn't care what system is used, as long as we communicate better with people contributing Nov 11 17:18:52 as I mentioned before there are some folks here at Intel in another team who are working on patchwork, I hope that we'll be able to take advantage of their improvements Nov 11 17:18:53 bluelightning: even marking patches as accepted doesn't work, I don't know how you would implement automatic update of Superseded, Rejected, .. Nov 11 17:19:04 ok Nov 11 17:19:21 maybe not rejected, but superseded on new versions being posted should be possible Nov 11 17:19:35 possibly even updates when a patch gets added/removed from a -next branch Nov 11 17:19:46 as long as the subjects remain the same/similar and are tagged as V2/V3, etc.. (which we seem to be pretty good at doing) Nov 11 17:19:58 * nerdboy assumes people have already discussed using an RC branch and not freezing master? Nov 11 17:20:07 fray: except subject fixes :) Nov 11 17:20:14 thats the 'similar' bit Nov 11 17:20:16 as to freeze etc, we could certainly sent more frequent mails as to release cycle state. i often forget where we are anyway... Nov 11 17:20:54 * JaMa likes Change-Ids in commit message, but it's confusing and annoying at first Nov 11 17:20:55 but ya, dramatic changes would be an issue.. unless we can key off the cover letter Nov 11 17:21:27 and in some versions of gerrit also buggy :/ Nov 11 17:21:27 nerdboy, we had a long time ago.. but we've not come back I think due to lack of resources being able ot manage the RC and master at the same time Nov 11 17:22:21 I'd certainly prefer all changes to master, and then backported to the 'freeze'/RC tree.. but so far I don't think it's been possible (like I said, lack of time/resources in managing it all) Nov 11 17:22:23 yeah, i was thinking that... Nov 11 17:22:41 people resources, or autobuilder resources? Nov 11 17:22:59 both.. but I think people resources more then autobuilder Nov 11 17:22:59 and quantity od... Nov 11 17:23:05 *of even Nov 11 17:23:24 well there is also master-next which can help a bit with this issue Nov 11 17:23:33 yes.. master-next I think has helped a lot Nov 11 17:23:50 it seems to be doing a good job catching issues before they affect the broader community.. Nov 11 17:24:09 at some point I'd like to see automatic testing of posted patches / branches shortly after they get posted Nov 11 17:24:21 does delayed/queued stuff go there? Nov 11 17:24:45 bluelightning: that would be awesome. isn't that something beth+intern was looking at? Nov 11 17:24:45 obviously we're a ways off being able to do that, but one can dream... Nov 11 17:24:46 bluelightning: very easy to do with gerrit+jenkins :) Nov 11 17:24:51 in a perfect world it would.. but it didn't (AFAIK) during the freeze period.. Nov 11 17:24:55 rburton: could be Nov 11 17:26:19 nm, i can find out later if i come up for air... Nov 11 17:27:03 ok, so anything further on the current dev cycle or patch management? Nov 11 17:28:26 FWIW, if you have feature requests or areas that should be looked into for OE-Core, please file them in the Yocto Project bugzilla Nov 11 17:28:57 I'll throw a bugzilla entry in for procps->procps-ng then Nov 11 17:29:04 paulbarker: thanks Nov 11 17:29:39 bluelightning: that automated testing would probably take quite some computing resources unfortunately Nov 11 17:29:59 The big issue with having multiple branches is that everyone ignores "stable" and just works on the dev one :( Nov 11 17:30:05 RP: right, but such things are not unprecedented Nov 11 17:30:21 master-next is as good a compromise as we've been able to find at least so far Nov 11 17:30:22 RP: we could start by having a "does it even parse" check... Nov 11 17:30:27 stable gets tested and released Nov 11 17:30:47 (or "does it even apply" before that) Nov 11 17:30:55 nerdboy -- problem is gets tested by 'testers', not users... Nov 11 17:31:13 we really need the users (developers, you guys) to test this stuff as well and report issues.. early.. Nov 11 17:31:25 i use what i test... i thought that was the point... Nov 11 17:31:34 seems like the bigger question is How do we get more people working on core stuff like this? Nov 11 17:31:41 yes -- but the majority of the world is either on 'master' or the last release.. Nov 11 17:31:43 instead of feeding patches into the machine Nov 11 17:31:52 Crofton|work: that is a good question Nov 11 17:31:58 we branch and 'freeze' and people ignore it.. suddenly users go way down until release.. which is a problem Nov 11 17:32:25 fray: you have stats? Nov 11 17:32:34 * Crofton|work is always looking for topics to liven up YP Adivosry board meetings Nov 11 17:33:23 bluelightning: yes, I guess I think in full autobuilder context Nov 11 17:33:54 imperical..just what I've seen on the list, and talking to developers here and at conferences.. Nov 11 17:33:54 RP: it would have to be separate from the autobuilder, or at least set up in a way that it would not get in the way of normal autobuilder use Nov 11 17:34:24 I'm convinced it can be done, and needs to be done once a project reaches a certain size Nov 11 17:34:31 bluelightning: we could do with more people involved with innovating with the autobuilder Nov 11 17:34:51 look at Chrome - that project wouldn't work at all without all of the similar automation they have for handling submitted changes Nov 11 17:35:17 something to think about, anyway Nov 11 17:35:39 we need soemthing to steer people at Nov 11 17:35:53 the key is perhaps autobuilder innovation Nov 11 17:35:59 and I need to prod AB memebers to encourage their staff to work on such things Nov 11 17:36:14 I agree.. I think it can be done -and- be helpful.. the catch is someone has to do the work to innovate and deal with our requirements.. Nov 11 17:36:26 Crofton|work: we don't have a good success track record with AB prodding :/ Nov 11 17:36:44 yes, but need to keep beating the drum Nov 11 17:37:01 do you have some estimate how many builds you do on AB per month? Nov 11 17:37:02 I also advise anyone who is a part of a member org to talk with your AB rep Nov 11 17:37:34 Maybe just try to build changed recipes for submitted patches rather than trying to do full image builds. It wouldn't be perfect but it could detect fetch/unpack/patch/configure/compile failures Nov 11 17:37:39 for reference, AB above can mean Autobuilder or (Yocto Project) Advisory Board Nov 11 17:37:59 I know Nov 11 17:38:02 sorry about that Nov 11 17:38:11 Crofton|work: for others benefit ;) Nov 11 17:38:13 yay, i guessed right twice Nov 11 17:38:13 we trigger ~ 3000 builds per month on relatively small build farm Nov 11 17:38:30 JaMa: how long do your builds run for? Nov 11 17:38:49 JaMa: I'd guess we're at a lot less than that, our builds are huge though Nov 11 17:39:04 * nerdboy awards himself an espresso Nov 11 17:39:06 between 30 and 300 minutes dependeing on ssstate reuse Nov 11 17:39:47 https://autobuilder.yoctoproject.org/main/tgrid and http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder/tree/buildset-config.controller might be interesting to anyone curious Nov 11 17:40:03 and I bet our builds are bigger :) Nov 11 17:40:32 JaMa: Ours are definitely more like an average of 400 minutes Nov 11 17:41:05 nightly-arm does core-image-sato -sato-dev sato-sdk -minimal -minimal-dev for qemuarm and beagleboard, and arm toolchains for 32 and 64-bit hosts Nov 11 17:41:06 JaMa: how many architectures? Nov 11 17:41:57 ok who crashed the ab Nov 11 17:42:18 4-6 MACHINEs which currently don't share anything (except native) Nov 11 17:43:56 JaMa: 10 machines not sharing anything over two distro configs + a load of misc tests Nov 11 17:44:17 actually, its more like 14 :/ Nov 11 17:44:38 and set to expand with these new qemu machines I would assume Nov 11 17:45:21 bluelightning: yes Nov 11 17:45:25 It'd take an insane amount of resources to build all that for every submitted patch or branch Nov 11 17:45:33 ok, I see, but for what bluelightning said we don't need to test all 14 to catch 90% of the issues Nov 11 17:45:47 right, I think that is what I said earlier :) Nov 11 17:45:48 right, you'd test a subset Nov 11 17:46:17 the autobuilder also needs reconfiguring to be more optimal Nov 11 17:46:18 for world builds I'm doing just 3 architectures and in most cases either all fail or all pass Nov 11 17:46:28 yup.. and that really is the goal.. do a representive set on the 'next'.. and do full builds ona regular basis to catch other issues Nov 11 17:47:34 We really need more build targets on the AB and more flexibility Nov 11 17:47:41 right now its either all or nothing pretty much Nov 11 17:48:40 oh, one thing I should mention Nov 11 17:48:55 Looking to the future with bitbake, I think we're going to need inotify support Nov 11 17:49:20 does anyone foresee problems with that? I will mention this on the lists but thought I'd mention here too Nov 11 17:49:32 what are you thinking? Nov 11 17:49:37 RP: to clarify, this is just when running memory resident right? Nov 11 17:50:07 when was inotify implemented? Nov 11 17:50:16 bluelightning: well, the other question is whether we make that mandatory Nov 11 17:50:18 early 2.6 right? Nov 11 17:50:24 I'm worried about too many codepaths :/ Nov 11 17:50:29 fray: yes Nov 11 17:50:35 2.6.13 I think Nov 11 17:50:53 so we should be fine there.. as buildtools (sdk) won't run on anything older then 2.6.34 Nov 11 17:51:55 RP: I'd be cautious about that, we'd need to be sure people are expecting it and that it was completely solid before doing that Nov 11 17:52:27 bluelightning: its a chicken and egg problem Nov 11 17:52:47 RP: well right now we know it isn't solid... Nov 11 17:53:15 bluelightning: I'm not suggesting we throw the default today Nov 11 17:54:08 RP: great, and I'm not saying we shouldn't ever do it either :) Nov 11 17:54:30 bluelightning: I am wondering if it should be a 1.8 target for example though Nov 11 17:55:04 I'm thinking that would be a little ambitious Nov 11 17:55:38 it's not as if that path won't be tested, Toaster relies upon it and the new Toaster functionality coming in 1.8 will bring more users of that Nov 11 17:55:53 [time check, 5 mins left] Nov 11 17:56:14 bluelightning: to be honest there is that much friction about changing anything these days I wonder why bother :( Nov 11 17:56:44 RP: in a system such as ours with a long history and a lot of users, we can't avoid it Nov 11 17:57:17 bluelightning: There are things that we shouldn't break but there are also things we should improve Nov 11 17:57:29 I do think we're becoming "stuck" Nov 11 17:58:12 Memory res bitbake has bugs today. The only real way to fix them is probably with something like inotify. That implies changes to the system. If we do the backwards compatible thing again, it means multiple code paths in the cache validation. I worry what that means for our already overloaded test matrix Nov 11 17:58:17 we just need to be careful Nov 11 17:58:56 are we trying to do to much with bitbake? Nov 11 17:59:15 Crofton|work: It needs to become a function librbary Nov 11 17:59:17 RP: well, our test matrix relies on full build tests and those aren't really geared to regression testing that level of functionality, we probably need to do more testing down at the lower levels Nov 11 17:59:27 yes Nov 11 17:59:30 we need more commands, wider usage and modular Nov 11 17:59:41 but to do that in itself means change (and really needs mem res) Nov 11 17:59:48 so we can build stuff against that lib to use the metadata/build system Nov 11 18:00:07 bluelightning: the answer here is not more tests, its less codepaths IMO Nov 11 18:00:40 ok, well we're out of time in any case, let's take this to the mailing list Nov 11 18:00:42 thanks everyone Nov 11 18:01:05 cheers Nov 11 18:01:48 Thanks guys Nov 11 18:03:07 thank you all Nov 11 18:09:52 RP, fwiw I think we need to have a raodmap for bitbake Nov 11 19:23:18 rburton: I've reproduced the core-image-sato-sdk do_rootfs failure with opkg v0.2.3 Nov 11 19:24:53 'perl' provides 'perl-module-config', but opkg can't find a provider of 'perl-module-config' Nov 11 19:26:42 see.. even opkg doesn't like perl.. Nov 11 19:40:39 fray: haha Nov 11 19:46:51 disgusting edge case, but the problem is obvious. I need to do some thinking on how to correctly fix it. Shouldn't take more than a couple of days Nov 11 20:09:00 paulbarker: at least you've found it! Nov 11 20:12:21 rburton: I'm just testing a quick fix now, then I'll send an email with more details Nov 11 20:12:58 do_rootfs is very slow when running opkg at the highest verbosity level Nov 11 20:13:14 oh, cool, it just succeeded Nov 11 20:14:00 hooray Nov 11 20:14:11 send a patch and i'll throw it at the AB Nov 11 20:15:38 I was planning to release opkg v0.2.4 this week anyway, I'll roll it into that Nov 11 20:15:58 So OE will skip v0.2.3 and go straight to v0.2.4 Nov 11 20:52:25 denix: What's the status of accelerated graphics for Qt5 on the BBB? Specifically for the X11 QPA? Nov 11 22:50:34 Crofton|work: agreed, I'm probably going to write something up and send it out Nov 11 22:50:47 thanks Nov 11 22:51:01 I fear bitbake becoming skynet Nov 11 23:50:05 is there a reason why we don't clean /var/lib/opkg/lists/* at the end of the image creation process? Nov 11 23:50:51 if I understand the code correctly, those feeds are used for building the image, but once the image is built, they are likely to be stale, and just take off space Nov 11 23:51:49 also, opkg is configured to look at /var/lib/opkg, so those feeds are not accessible unless you modify opkg.conf manually Nov 12 00:58:23 darknighte: should basically work **** ENDING LOGGING AT Wed Nov 12 03:00:00 2014