**** BEGIN LOGGING AT Tue Jan 07 02:59:58 2014 Jan 07 05:59:50 hello. I cannot build db 5.3.21. the recipe tries to link against the host's /usr/lib/libstdc++.so Jan 07 06:00:40 in the linker call that tries to output the db shared object, I see this part that looks erroneous: -L[my OE directory]/tmp/sysroots/hummingboard/usr/lib /usr/lib/libstdc++.so -lm Jan 07 06:01:05 (I put a placeholder in the path to shorten it a bit) Jan 07 06:01:27 any ideas? Jan 07 06:38:53 dv_: check config.log to see what put it there Jan 07 06:46:54 JaMa: ok, I will do that later then. for now I just reverted the commit that enabled the c++ library, since I first need to make sure some other recipes work. Jan 07 07:48:27 hi koen, your commit "649671e auto-serial-console: update license checksum to match OE-core" in meta-linaro/master breaks dora builds. so far the recommendation was to use meta-linaro/master for dora build, sounds like we need a dora branch now.. Jan 07 07:48:49 ideally, the dora branch should start before this commit. Jan 07 08:18:59 right Jan 07 08:19:03 so Jan 07 08:19:14 has any figured out how to make branches with gerrit yet? Jan 07 08:23:20 koen: i think someone with enough permissions to 'push' a branch to bypass the review system. i guess fabo can do that. Jan 07 08:23:33 then, we need to update the .gitreview in that branch. Jan 07 08:28:28 not sure if I have the right ssh key ready Jan 07 08:28:42 * koen is working from a VM till lenovo delivers the new laptop Jan 07 08:29:46 * fabo reads backlog Jan 07 08:30:53 ndec: do you still use gcc-4.7 for your builds? Jan 07 08:33:58 fabo: yes. Jan 07 08:34:04 still dylan. Jan 07 08:34:24 but we have dora builds too, that use 4.8 as well. Jan 07 08:35:03 ok Jan 07 09:57:24 morning all Jan 07 09:59:20 good morning Jan 07 10:01:30 OutBackDingo: happy new year Jan 07 10:17:57 morning all Jan 07 10:19:06 hi apelete, all Jan 07 10:24:24 mckoan: hi Jan 07 10:24:25 bluelightning: I successfully updated the linux-jlime-ben-nanonote kernel recipe to version 3.12 last night Jan 07 10:25:00 bluelightning: did it because I wrote a kernel driver to provide upstream usb support for the ben nanonote (to replace the out-of-tree usb driver we were using until now) Jan 07 10:26:14 bluelightning: the usb driver patches will land in kernel 3.14 (along with other patches to provide full upstream support for the ben), in the mean time the new oe recipe relies on the qi-hardware community kernel 3.12 Jan 07 10:29:00 bluelightning: so I'm going to send a patch to oe-devel when I get back from work tonight, to get those changes into meta-handheld if that's ok Jan 07 11:14:33 guys: is OE running all tests now during build? Jan 07 11:21:28 hrw: er, which tests? Jan 07 11:21:36 probably the answer is no Jan 07 11:22:02 bluelightning: "make check" ones which take enourmous amount of time Jan 07 11:27:02 hrw: in poky we have enabled ptest in the default value of DISTRO_FEATURES Jan 07 11:27:42 that does not actually *run* the tests though, just sets things up so they can be installed and run at runtime Jan 07 11:28:18 and I don't think that is enabled in OE-Core's DISTRO_FEATURES value Jan 07 11:29:20 ok Jan 07 15:26:42 bluelightning: I just got your email for the TSC Jan 07 15:27:20 abelloni: yep, it was a bit late I know Jan 07 15:27:22 unfortunately, I won't be available but I'm quite interested in the x11-common/xserver-common issue Jan 07 15:27:34 abelloni: right, I saw your thread Jan 07 15:27:43 the bug to fix it is assigned to me FWIW ;) Jan 07 15:27:51 yeah I know :) Jan 07 15:28:35 one of the questions that wasn't answered was why the conflicting is not working Jan 07 15:29:46 there is RCONFLICTS_${PN} = "xserver-kdrive-common x11-common" in xserver-common Jan 07 15:30:25 so I would think x11-common wouldn't be built Jan 07 15:30:27 is that conflict only for the final installation on the target? Jan 07 15:31:05 note the 'R'. runtime, not build time Jan 07 15:31:09 aaaaaaaaaaaaah :) Jan 07 15:31:35 ok thanks Jan 07 15:32:50 so, I'm off to watch the hobbit, it is my last chance to see it Jan 07 15:52:50 * koen gets TZ conversion wrong again Jan 07 15:53:04 and bluelightning actually specified the TZ I'm in in his mail Jan 07 15:54:34 :) Jan 07 15:54:56 T-65m right? Jan 07 15:55:40 When will be the TSC meeting? Jan 07 15:55:49 in approx one hour Jan 07 15:55:55 like JaMa said :) Jan 07 15:56:08 * otavio didn't see it Jan 07 15:56:40 * otavio didn't get the e-mail :-( Jan 07 15:56:52 fuck; I did Jan 07 15:56:55 :-( Jan 07 15:56:56 heh Jan 07 15:59:04 heh Jan 07 16:00:56 koen: yes, I might have got it completely wrong last time ;) Jan 07 16:46:23 reminder - OE TSC / workgroup meeting will be here in ~15 mins, all welcome to participate Jan 07 16:49:48 bluelightning: as always it starts 5 minutes after my pizza arrives :) Jan 07 16:50:07 * koen still doesn't understand how that goes wrong every meeting Jan 07 16:50:31 mmm pizza Jan 07 16:50:38 lol.. Jan 07 16:50:55 and now I'm hungry... Jan 07 16:50:58 reminds me, I need to grab a snack BEFORE the meeting.. Jan 07 16:56:52 t minus 4 minutes Jan 07 16:59:53 :) Jan 07 16:59:57 1m Jan 07 17:00:31 !startmeeting Jan 07 17:00:40 hmm, fail Jan 07 17:00:48 ;) Jan 07 17:00:58 ah Crofton|work's bot isn't around Jan 07 17:01:08 we'll just do things the old fashioned way I guess Jan 07 17:01:24 find Jefro and get him ot do it? Jan 07 17:01:25 ;) Jan 07 17:01:38 so, from the TSC we have myself, fray, and koen Jan 07 17:01:48 RP? Jan 07 17:01:48 hnag on Jan 07 17:02:03 no sign of khem Jan 07 17:02:24 I havn't seen him since the New Year, so he may still be on vacation Jan 07 17:02:34 !startmeeting Jan 07 17:02:35 fray: you mean hangover? Jan 07 17:02:48 not khem :) Jan 07 17:02:54 Crofton|work: am I doing it right? Jan 07 17:03:03 use a # Jan 07 17:03:10 #startmeeting Jan 07 17:03:10 Meeting started Tue Jan 7 17:03:10 2014 UTC. The chair is bluelightning. Information about MeetBot at http://wiki.debian.org/MeetBot. Jan 07 17:03:10 Useful Commands: #action #agreed #help #info #idea #link #topic. Jan 07 17:03:11 aha Jan 07 17:03:17 cool Jan 07 17:03:24 #chair fray koen khem RP Jan 07 17:03:24 Current chairs: RP bluelightning fray khem koen Jan 07 17:03:26 the do #chair the nicks you want to hav emore power Jan 07 17:03:32 done ;) Jan 07 17:03:36 usefule so they can do tpoic and action Jan 07 17:03:40 * RP is here Jan 07 17:03:54 ok cool Jan 07 17:04:03 Jefro: are you around by chance? Jan 07 17:04:08 bluelightning I'm here Jan 07 17:04:15 great! Jan 07 17:04:32 do we have an agenda? Jan 07 17:04:58 aaah.... that I could not say, sorry - I haven't been to a meeting in a while Jan 07 17:05:09 when was the last meeting? Jan 07 17:05:17 right, it's a bit unfair, sorry... Jan 07 17:05:29 was the last meeting before ELC-E? Jan 07 17:05:40 srsly? then I may be able to put together an agenda Jan 07 17:05:56 anyone want to chair? Jan 07 17:06:23 at the very least I can bring up lingering issues after people bring up new ones Jan 07 17:06:33 I ahve a file from 11/5 last year Jan 07 17:06:44 that would have been right then.. Jan 07 17:07:02 Crofton|work just after ELCE - can you send it to me Jan 07 17:07:30 so first order of business then I guess is chair and opens.. Jan 07 17:07:31 otw to Jefro Jan 07 17:07:49 blue seems to doing well as the chair.. :) Jan 07 17:07:55 ok, I'll do it ;) Jan 07 17:07:57 any issues people would like to talk about? (open to all on the channel) Jan 07 17:08:20 I've been asked to raise the x11-common/xserver-common conflict issue Jan 07 17:08:26 just wondering if/when qt5 will become the default (i.e. part of oe) Jan 07 17:08:50 and will qt4 stay in core Jan 07 17:08:59 RP and I discussed concerns with oe-core mailing list and patch review before.. I can say a few things about that if RP doesn't want to.. Jan 07 17:09:03 ok Jan 07 17:09:13 I'd also like to raise a couple of issues myself - 1) bug count and 2) absentee layer maintainers Jan 07 17:09:22 I think someone brought up (IRC?) the other day about a janitorial day/week? Jan 07 17:09:27 sorry, i don't always have time to keep up to date with all the mailing list postings :-( Jan 07 17:09:28 fray: does that include pull requests not matching the emailed patches? Jan 07 17:09:43 koen, yes partially Jan 07 17:09:59 I don't think I have anything specific to talk about Jan 07 17:10:20 * RP is still trying to catch up on the backlog after the holidays Jan 07 17:10:37 looks like several new issues. I have a shortlist of issues discussed at the November meeting Jan 07 17:10:46 I spotted that initrdscripts/init-live is in very bad contidion, have some fixes for that Jan 07 17:10:52 we should mention LAVA evaluation, although it sounds like progress is being made Jan 07 17:10:52 RP: I had 2 weeks worth of autobuild failure emails :) Jan 07 17:11:00 tlwoerner: what's problem with using extra layer meta-qt5? Jan 07 17:11:06 * otavio is here Jan 07 17:11:13 hi otavio Jan 07 17:11:39 hang on let's discuss each issue in order Jan 07 17:11:40 JaMa: oh, nothing at all, it's just that qt is now at qt5.3 and qt4 is getting old Jan 07 17:11:47 koen: those are the least of my worries ;-) Jan 07 17:12:06 tlwoerner: meta-qt5 has 5.2.0 branch Jan 07 17:12:51 rudimentary schedule coming in a few seconds Jan 07 17:12:59 Jefro: thanks Jan 07 17:13:10 okay, i'll wait for the schedule :-) Jan 07 17:13:24 the piglit QA question Jan 07 17:13:44 actually let's jump right in on the qt5/qt4 thing Jan 07 17:13:51 okay Jan 07 17:13:52 #topic qt in OE-Core Jan 07 17:13:54 naming of meta-yocto and meta-oe/meta-oe Jan 07 17:14:15 JaMa: my "gut feeling" is that if someone were new to OE and were putting together a GUI image they might be surprised that qt4 is the default Jan 07 17:14:28 but that's just my opinion Jan 07 17:14:31 Personally I am in favor of having Qt5 in a layer Jan 07 17:14:55 I know in the past we'd discussed removing qt from oe-core, in favor version(s) in layers.. Jan 07 17:15:03 agenda is here: http://pastebin.com/QvrfH8rp Jan 07 17:15:04 the concern was always mainteance, since we needed "something" Jan 07 17:15:06 I have to be honest and say I'd prefer it in core... but that's because I'd like to have it available to people out of the box Jan 07 17:15:08 People have a perception that is something isn't in core, it is bad Jan 07 17:15:14 tlwoerner: agreed; but this user will soon learn he needs other layers for extra things so sooner or later he/she will get to it anyway Jan 07 17:15:27 but I think that is not a good reason to put soemthing in core Jan 07 17:15:36 Crofton|work, I think thats something we need to work to resolve -- but just blindly expecting a layer to have good quality won't work either.. Jan 07 17:15:37 I prefer separate layer too, because we shouldn't put everything to oe-core, we don't have any app/lib in oe-core depending on qt5 now Jan 07 17:15:45 fray +1 Jan 07 17:15:52 you can put a seperate layer into the oe-core repo Jan 07 17:16:14 I have to admit I'm in favour of having a good core of things and I do like having some of the basics like qt in there Jan 07 17:16:23 we really need to worry about what uses a recipe, and use that to determine what layer something belongs in Jan 07 17:16:24 and yes, you could still separate this to meta-qt5 in core Jan 07 17:16:48 as in we may still ahve more stuff using qt4 and not qt5 Jan 07 17:16:53 I'm equally happy to have others help maintain it in core, I already do "delegate" certain things to certain people Jan 07 17:16:55 could wwe have both in core? Jan 07 17:17:08 I think maybe we need some sort of quality rating / approval mechanism for the yocto project to indicate that this layer which isn't part of oe-core is nonetheless still maintained and high quality Jan 07 17:17:09 * kergoth shrugs Jan 07 17:17:15 we could, I don't think it has to be an "or" Jan 07 17:17:20 I don't disagree qt is generally needed and useful for embedded.. but I'm still torn if it belongs in the actual "core" (meta).. but a meta-qt* would resolve some of that for me Jan 07 17:17:21 In fact I think in future qt4 (as qt3) ought to be moved to a layer too Jan 07 17:17:28 the difference with qt5 is that it's not just 2-3 recipes, but currently 25 recipes Jan 07 17:17:34 one way we could do this is do auto inclusion into meta-yocto Jan 07 17:17:52 i.e have it separate to core but include it in the official "yocto" reference using combo-layer Jan 07 17:17:56 kergoth: like the yocto compat thing? Jan 07 17:18:04 RP: this would 'duplicate' things Jan 07 17:18:23 RP, that would definitely enable more automated testing.. Jan 07 17:18:31 and this would deny any kind of 'merging' (just fast-forward) pushed in meta-qt5 Jan 07 17:18:37 pretty much... I think people need to stop avoiding inclusion of external layers so much, but to do that we'd need to have a certain level of confidence in the quality of 3rd party layers Jan 07 17:18:41 to be clear, I mean importing meta-qt5 into poky using combo-layer Jan 07 17:18:43 and perhaps adding a quality comment or something to the layer website would be useful.. (review field?) Jan 07 17:18:57 policing it could be a pain over time..but it could prove useful Jan 07 17:18:58 so it would not be in meta-yocto, it would be in the poky repo which is already "generated" Jan 07 17:19:05 RP: why we don't just add meta-qt5 in the daily builds and it being part of build helps to spot things early Jan 07 17:19:29 otavio: because OMG external layers are BAD!!!!One!!!! Jan 07 17:19:45 koen: not nice colorful boxes? :/ Jan 07 17:20:02 koen, we all agree that attitude needs fixing Jan 07 17:20:07 otavio: there are a number of different things here and we need to be clear about what they all mean Jan 07 17:20:11 i was surprised when Crofton mentioned there is a perception that extra layers are bad, the whole point of OE is to put things into layers :-) Jan 07 17:20:13 adding to the AB is one issue Jan 07 17:20:33 That one is a question of resources, who is going to fix any issues and then fix any new issues on a continual basis? Jan 07 17:20:36 I kind of disagree with this policy of Poky not testing external layers; we advise for our users to use layers so adding meta-qt5 in testing would help boosting its quality Jan 07 17:20:42 tlwoerner: with the minnowboard I had to fight to make meta-minnow an external layer Jan 07 17:21:01 tlwoerner: 'cause the intel people involved thought that external layers were bad Jan 07 17:21:04 otavio: I agree with you there Jan 07 17:21:04 secondly, how can yocto indicate a given layer is of a quality? including it in poky (yocto's reference) demonstrates that Jan 07 17:21:11 tlwoerner: kinda ironic, seeing that meta-intel is external Jan 07 17:21:16 we'd have to get AB builds clean before we'd include in poky Jan 07 17:21:21 koen: :-) Jan 07 17:21:34 there is no message about external layers being bad Jan 07 17:21:46 wanting a core which is testable is different to that Jan 07 17:22:00 the Yocto AB already has meta-intel, meta-fsl and meta-qt3 in there iirc Jan 07 17:22:08 at least for some of the tests Jan 07 17:22:42 everytime you write Yocto AB, I see advisory board Jan 07 17:23:06 it appears there are two issues: 1) should qt be part of oe-core? and 2) what should be? 3, 4, 5? Jan 07 17:23:08 Crofton|work: this always confuses me too :) Jan 07 17:23:28 tlwoerner: qt3 clearly isn't. We do test it and include it for lsb reasons but its on the way out Jan 07 17:23:49 qt5 on the other hand is on the way in Jan 07 17:23:59 RP: how do we decide/define when a version is "on the way out"? Jan 07 17:24:13 "wanting a core which is testable" I think that one of the most important tests is to see that oe-core can be used together with layer-X, because layers is one of main concepts Jan 07 17:24:19 when will qt4 be "on the way out"? Jan 07 17:24:42 tlwoerner: that's a very good question Jan 07 17:24:54 tlwoerner: gauging demand, lsb is one (arguably bad) way to do that Jan 07 17:25:02 what about considering upstream? Jan 07 17:25:19 are there any new upstream releases of qt4? (sorry, i'm not that close to the project) Jan 07 17:25:23 tlwoerner: if we can say there aren't that many folks needing to use it, I'm in favour of moving it out to a separate layer a la meta-qt3... but how do we make that determination? Jan 07 17:25:26 tlwoerner: it also comes into it. qt3 is pretty dead by several measurements Jan 07 17:25:52 I see few bug reports about qt3, more about qt4 and qt5 for example Jan 07 17:25:55 everyone I've talked to has said the exiting qt integration (4?) isn't useful without a lot of mods to their specific project.. Jan 07 17:26:08 so they either re-do it, or heavily patch it.. Jan 07 17:26:18 RP: importing it to meta-yocto does not improve meta-qt5 quality so it is the same as including it externally Jan 07 17:26:20 fray: but having somewhere to start helps? Jan 07 17:26:21 that to me is another reason to move it into a layer.. make it easier for the replacement side Jan 07 17:26:22 bluelightning: i'm recommending upstream interest, in what state to the upstream developers consider it? Jan 07 17:26:36 otavio: as I said, it would be to poky, *not* meta-yocto Jan 07 17:26:36 RP, I really am not familiar with QT.. so I'm only repeating what I've heard.. Jan 07 17:26:52 and the couple of people who complained to me said it wasn't even very useful as a starting point due to the amount of tailoring they needed.. Jan 07 17:27:00 RP: about quality 'tag' I agree but we cannot 'merge' all in poky which we want to users to use Jan 07 17:27:10 but thats from one small group of people at one conference I attended.. so take it with a large grain of salt Jan 07 17:27:11 RP: or Poky will start to grow and grow Jan 07 17:27:14 otavio: poky is a generated repository of multiple combined layers even now Jan 07 17:27:20 RP: I know it Jan 07 17:27:27 otavio: well, we need to be selective about what goes there Jan 07 17:27:28 I used combo-layer for a while Jan 07 17:27:35 I'm not concerned with Poky growing.. since it's a "distribution" vs the core.. it doesn't worry me Jan 07 17:27:40 upstream said in August "There are no plans to stop releasing 4.8 so far" FWIW Jan 07 17:27:41 otavio: if meta-qt5 doesn't make oe-core, it could still make poky Jan 07 17:28:06 What I mean adding meta-qt5 to poky does not make qt5 better quality wise Jan 07 17:28:21 bluelightning: okay, thanks Jan 07 17:28:22 and we promote the layer use; so we ought to eat our own dog food Jan 07 17:28:23 otavio, it does mean more auto builder coverage... Jan 07 17:28:31 I'd guess qt4 is years from being obsolete. Its taken qt3 at least 5 years to die off? Jan 07 17:28:31 but thats distro specific not OE Jan 07 17:28:43 otavio: stop making sense! Jan 07 17:28:53 fray: sure but adding it as a layer or merged does not change the resource usage Jan 07 17:28:54 RP: is qt3 still lsb mandated? Jan 07 17:28:56 koen: ? Jan 07 17:29:02 koen, yes Jan 07 17:29:04 koen: right now I think yes but due to be dropped Jan 07 17:29:27 my thoughts are we drop it when lsb does as its the last reason to have it around Jan 07 17:29:33 ...and LSB matters for higher end embedded systems.. i.e. Carrier Grade and other server like systems.. Jan 07 17:29:43 RP, I agree completely Jan 07 17:30:00 RP: okay, sounds good Jan 07 17:30:17 RP: agreed about qt3 Jan 07 17:30:25 also agreed re qt3 Jan 07 17:30:30 * tlwoerner wonders if LSB will drop qt3 in favour of qt5 :-D Jan 07 17:30:42 my guess is qt4 and qt5 will be required.. Jan 07 17:30:49 but thats an uninformed guess at this point Jan 07 17:30:49 yes, that's what I would think Jan 07 17:31:08 so if LSB requires both qt4 and qt5 then we'll add both to oe-core? Jan 07 17:31:14 AFAIK it was the same situation when the last LSB came out, Qt4 was new-ish and qt3 was still heavily used Jan 07 17:31:20 LSB support is in Poky, not directly in oe-core.. Jan 07 17:31:30 fray: right... sorry Jan 07 17:31:49 isn't there a meta-lsb? Jan 07 17:31:55 I'd in favor of a meta-lsb-support or something Jan 07 17:31:56 anyway I think we need to move this discussion to the ML, we've talked about it for a while here Jan 07 17:32:06 Good Jan 07 17:32:09 agreed Jan 07 17:32:10 koen: recipes-lsb4 Jan 07 17:32:12 sounds good Jan 07 17:32:17 koen: Qt3 has been dropped since lsb 4.0 Jan 07 17:32:35 * Jefro has never seen the word "agree" show up so many times consecutively on #oe Jan 07 17:32:42 koen: in 2009 Jan 07 17:32:56 fabo: wow, 2009 Jan 07 17:33:15 last time I ran the LSB test suite (6 months ago?) it was still checking for qt3 libraries and failing if they weren't there Jan 07 17:33:47 fray: does the LSB do a good job of keeping its test suite up-to-date? Jan 07 17:34:05 ok, let's move on down the agenda - bug count Jan 07 17:34:07 it's 'supposed to'.. but the test suite is the only way to get compliance.. so thats the requirement Jan 07 17:34:10 #topic bug count Jan 07 17:34:17 so when I see "testable" I don't think it has to be all in one layer or one repository Jan 07 17:34:52 JaMa: +1 Jan 07 17:34:57 bug count -- related item.. prior to the december holidays RP and I were talking about seemingly less participation on the list(s) for reviewing of patches, which unfortunately was causing more bugs to go in.. Jan 07 17:35:11 so we're building up bugs in YP bugzilla, many of which are against parts of OE-Core, and I think it's fair to say we're struggling to keep the number under control Jan 07 17:35:13 so for any bug count discussion, I just ask people to try to help review patches when they can Jan 07 17:35:20 fray: sorry, my bad. you're right it's still in lsb 4.1 Jan 07 17:36:01 Crofton was suggesting some sort of bug fixing sprint(s) as a possible solution Jan 07 17:36:06 any other ideas? Jan 07 17:36:11 bluelightning: I like it too Jan 07 17:36:12 +1 for a joint sprint Jan 07 17:36:15 on some other projects, code isn't pushed until there is at least one "reviewed-by" (or similar) on the mailing list in response to the patch Jan 07 17:36:26 now would be a good time to try to figure out if we can get the participation to do that.. Jan 07 17:36:28 I do remember the bug fixing sprints OE had back in time working well Jan 07 17:36:40 bluelightning: we used to do Debian Bug Squashing Party during weekends and it worked very well Jan 07 17:36:43 but in this project that doesn't seem to be a requirement Jan 07 17:36:46 We could poll the Yocto AB members and see if they could direct some of their employees to help out too Jan 07 17:36:49 RP: I never participated in one of those - was it in-person or via IRC? Jan 07 17:36:49 we've got a lot of janitorial issues, a lot of bug reports, etc.. and if we could eat away that would help out a lot.. (along w/ patch reviewing) :) Jan 07 17:36:53 just having other people about and willing to discuss ideas is usually enough to clarify/justify perceptions Jan 07 17:36:56 bluelightning: IRC Jan 07 17:37:14 so there was a time in the past when i would try to look at patches, apply them, and test them Jan 07 17:37:15 bluelightning: people had clear time to spend on issues and coordinated via irc Jan 07 17:37:18 reviewed-by works well.. I think our issue is the quality went up, people got busy and so fewer folks are reviewing patches.. Jan 07 17:37:27 but then realised that the code was pushed long before i could get through any such cycle Jan 07 17:37:31 we used to do Fri-Mon so employees as well as volunteers could participate Jan 07 17:37:57 RP: so it was spread over 4 days? Jan 07 17:37:58 so there's less incentive to work with patches on the mailing list Jan 07 17:38:07 i might just as well wait for it to hit master and then try testing Jan 07 17:38:25 tlwoerner: the time it takes for patches to go in varies, depends what my confidence level is in the patch, whether I think its controversial or not and a whole load of other factors Jan 07 17:38:37 tlwoerner: it does not bypass the process but we can have a 'fast-path' for the patches I think Jan 07 17:38:43 bluelightning: we set aside two week days and a weekend, yes Jan 07 17:38:52 we have participants in all geo's.. so even a 'fast-path' patch should have time to be reviewed by someone... Jan 07 17:39:33 tlwoerner: I can leave patches for a few weeks and nobody will pay attention to them but the longer I leave things, the harder it is to track what state anything is in :/ Jan 07 17:39:43 I noticed a "OE review cycles are way too long, import everything into our own layer" commit in our gerrit Jan 07 17:39:46 fray: For Debian we used to have a special upload queue so maintainer could reupload before 2-5 days. We could have something similar. Jan 07 17:40:02 I haven't investigated how long is "too long" Jan 07 17:40:16 koen, well I'm hearing too short, and too long.. Jan 07 17:40:24 koen: :/. I'd be interested in feedback on which area that was in as well as what "long" means Jan 07 17:40:54 I've had patches with no feedback that have gone for weeks.. and been (IMHO) rightly ignored because of lack of feedback (and followup).. Jan 07 17:40:58 RP: i'm not suggesting the current practice should be changed, i'm just saying that hoping people will review/test patches doesn't work with the current practice Jan 07 17:41:19 I think some high impact patches goes fast (for example the Git fetches which demanded branch setting) and some trivial patches waits too long sometimes. Jan 07 17:41:21 tlwoerner I see it working, when a patch fixes or addresses an issue someone else has.. Jan 07 17:41:24 tlwoerner: right, I'm just putting the other side over too. There are a lot of competing pressures Jan 07 17:41:26 But in general it works fine for me. Jan 07 17:41:34 RP: the other problem is that it lumps oe-core+meta-oe+...+... together as 'oe' Jan 07 17:41:37 IMO, I think we still have a problem with visibility of outstanding patches... patchwork doesn't manage itself very well; if it did that would be a huge improvement Jan 07 17:41:47 I know e.g. meta-hava patches will take months Jan 07 17:41:51 but that would take someone fixing patchwork Jan 07 17:41:51 java* Jan 07 17:42:23 koen: right, oe-core does try to be responsive, I know we have challenges for some of the other layers. There is another agenda item about that Jan 07 17:42:48 bluelightning: I do have a local way I manage patches which I should probably teach patchwork Jan 07 17:42:51 There's some sample scripts in patchwork tools directory for updating the status of patchwork when patches are pushed, dunno if you've seen them. Jan 07 17:42:54 yes; agreed. As I said it has been working fine for me most of time. Jan 07 17:43:01 fray: yes, i agree. the current practice with this project appears to be to push quickly to master so lots of people test, then provide fixes to any found issues; which is a great system Jan 07 17:43:03 bluelightning: it would swing the other way but not in a way I believe would be too problematic Jan 07 17:43:05 broonie: I think we use them, but there are bugs... Jan 07 17:43:23 I do work off the theory that master is a development branch Jan 07 17:43:29 and not all pull requests match the review patches Jan 07 17:43:36 I've been bitten by that a few times Jan 07 17:43:39 ya, but that leads to the competing quality pressure of 'too many bugs' Jan 07 17:43:48 koen: me too Jan 07 17:43:52 I wish there was a tool to check how often that happens Jan 07 17:43:54 I agree that patches should go to master soon(ish), problem is that found issues aren't usually resolved very soon Jan 07 17:44:25 JaMa: I know there are some exceptions (recent git issue) but I didn't think we were doing too badly :/ Jan 07 17:44:54 e.g. freetype upgrade breaks 4 recipes in meta-oe and the upgrade alone looks safe (so I wasn't trying to actively review it when it was on oe-core ML) Jan 07 17:44:56 broonie: yes, we do use them, they could use work :/ Jan 07 17:45:15 but first world build reveals that it's quite incompatible with old version and more recipes need to be updated to work with that Jan 07 17:45:17 JaMa: ah, from the meta-oe perspective :/ Jan 07 17:45:31 see, external layers are bad Jan 07 17:45:33 koen: FWIW, our pull request scripts actually check the branch has been pushed before creating the emails Jan 07 17:45:36 everyting into the core! Jan 07 17:45:37 RP: yes wasn't trying to say that you're doing it badly Jan 07 17:45:51 anyway... the topic was "bug count" and we've drifted to "development methodology" Jan 07 17:46:02 yes, we have moved somewhat off-topic Jan 07 17:46:03 just that it's hard to see which patch on ML is "dangerous" and should be put on hold for a bit longer and somehow make people to test it more Jan 07 17:46:06 mostly constructively though Jan 07 17:46:06 bluelightning: but it can't check if the branch is different or even updated after the fact Jan 07 17:46:16 I think we all agreed that a sprint might work fine Jan 07 17:46:17 not that i disagree with the new topic :-) Jan 07 17:46:29 koen: no it can't.. perhaps you'd like to write something that would ;) Jan 07 17:46:37 time check: we're 3/4 through the time slot Jan 07 17:46:50 In the past we (over time) constructed a list of core components.. toolchains, rpm [package manager], freetype, etc.. that required extra testing before going it.. Jan 07 17:46:57 * RP needs to be afk in 15 mins :( Jan 07 17:46:57 bluelightning: I love to violate causality Jan 07 17:46:58 perhaps something like that could be used to help adjust the time scales Jan 07 17:47:00 indeed, we need to come back to this but we probably should move on Jan 07 17:47:05 this is good discussion though Jan 07 17:47:22 let's quickly cover absentee layer maintainers Jan 07 17:47:25 #topic absentee layer maintainers Jan 07 17:47:25 quick poll: if we had a weekday bug sprint who could take part? Jan 07 17:47:26 JaMa: btw ,that grub build issue seems to be a bug in rpm/debugedit Jan 07 17:47:37 * otavio would be in Jan 07 17:47:42 * tlwoerner could take part Jan 07 17:47:44 do we have many people on weekends these days or should we try for two weekdays? Jan 07 17:47:46 koen, I thought that got fixed.. Jan 07 17:48:00 I think we're more active on weekdays now based on when I see patches Jan 07 17:48:03 RP: I'd do one, and see how it works Jan 07 17:48:03 FWIW, with this I was talking about some layers where patches have been sitting for months, and in at least one case the maintainer is not responding to emails Jan 07 17:48:11 how do we deal with that kind of situation? Jan 07 17:48:21 e.g. meta-mono Jan 07 17:48:22 * JaMa things about meta-perl/meta-filesystems Jan 07 17:48:27 thinks Jan 07 17:48:27 JaMa: yep, those too Jan 07 17:48:37 bluelightning: I think it should come to the TSC to do "something" with Jan 07 17:48:48 ya.. I agree.. Jan 07 17:48:48 is there a list of layers with absentee maintainers? Jan 07 17:48:49 * otavio is relif to people to not point at him and meta-fsl-arm Jan 07 17:48:50 which is probably appoint an interim maintainer Jan 07 17:48:51 heheh Jan 07 17:48:54 find a volunteer maintainer, fork, enjoy Jan 07 17:49:07 koen, we shouldn't need to fork though Jan 07 17:49:09 if the original maintainer shows up again, TSC gets to sort it out Jan 07 17:49:12 * JaMa points at koen/dora :) Jan 07 17:49:30 no need to fork IMO, its git, we can deal with things Jan 07 17:49:30 koen: in some cases the layers are under OE/YP control, so we have the technical means to get access, but perhaps not the process Jan 07 17:49:34 fray: we do if we don't have access to the external repo Jan 07 17:49:44 fray: it depends if they provide access for it Jan 07 17:49:50 fray: otherwse we will do Jan 07 17:49:51 I'm refering to OE/YP controlled layers Jan 07 17:49:53 bluelightning: for yocto stuff if comes back to me and I'd do roughly what the OE TSC would do Jan 07 17:50:11 JaMa: yeah, funny story, it involves retiring the machine with proper ssh keys too early Jan 07 17:50:21 JaMa: UPS says the new machine will get delivered this week Jan 07 17:50:44 so ya.. I'd say if you are seeing layers (OE) not maintained let the TSC know and we'll take an action to get things resolved.. Jan 07 17:50:46 koen: ok fair enough, it's not big issue for me as long as you're happy with patches I merge :) Jan 07 17:51:05 would it be safe to say a layer like meta-qt5 should be under oe/yocto control and not on github? Jan 07 17:51:25 tlwoerner: JaMa and I discussed about this and we enjoy the github for this moment. Jan 07 17:51:29 JaMa: agree? Jan 07 17:51:31 tlwoerner: it's under my and otavio's control, so I think this github is safe Jan 07 17:51:33 fray: ok... that sounds reasonable, if we have another candidate maintainer; that might not always be the case though Jan 07 17:51:47 okay, i was just considering "bus theory" Jan 07 17:51:47 tlwoerner it's up to the maintainer IMHO.. but that is something I'd certainly say we'd be happy to host.. Jan 07 17:51:48 I would like to see key OE layers on Yocto or OE infrastructure just to try and keep the core in one place and clearly visible. Its up to the maintainers though Jan 07 17:52:13 bluelightning we'll need to do something, even if that something is declare a layer unmaintained until someone (or group) can step up.. Jan 07 17:52:21 well layerindex is doing great job "promoting" layers Jan 07 17:52:23 making it look 'maintained' when it isn't doesn't help anyone.. Jan 07 17:52:32 ya, I lvoe the layer index Jan 07 17:52:33 so I think that it's not so important to see them all in one cgit UI Jan 07 17:52:34 fray: right Jan 07 17:52:38 bluelightning: right, we can put something into the README about the status Jan 07 17:52:38 bluelightning: the layerindex could have a 'flag' maintained/active or so Jan 07 17:52:52 can we start to address the issue of absentee maintainers by creating a list of such layers that appear to be abandoned? Jan 07 17:52:57 I'd like to see more support on yoctoproject.org for updating mirrors hosted there. For example, mentor prefers github for day to day workflow, but would like to keep the yoctoproject.org one currnet. currently we have our own scripts for that. but it'd be nice to e.g. be able to use github webhooks to poke a service on the yoctoproject.org site to trigger a mirror update Jan 07 17:53:08 otavio: we could yes... we do at least have a "last updated date" shown which is just the date of the last commit Jan 07 17:53:16 kergoth: talk to halstead, we can do this Jan 07 17:53:17 not directly related, but wanted to mention it before i forgot :) Jan 07 17:53:25 k Jan 07 17:53:41 at WR, we have all of our mirrors internally, and just pull at intervals.. Jan 07 17:53:50 (and yes, yocto is happy to mirror key repos) Jan 07 17:53:56 then we can geographically distribute them as necessary Jan 07 17:53:58 bluelightning: yes but this does not relate to it be /active/ and/or responsive Jan 07 17:54:08 ah openembedded/oe-core (not openembbedded-core name) mirror on github was also discussed lately, but that's kind of OT now Jan 07 17:54:16 otavio: sort of but not directly Jan 07 17:54:29 ok, probably time to move on again, good input from everyone though Jan 07 17:54:45 back on the bug topic, I think we should pick two days and organise a bug scrub Jan 07 17:54:57 ok Jan 07 17:54:59 +1 Jan 07 17:55:02 RP: +1 Jan 07 17:55:13 #action pick two days for a bug scrub Jan 07 17:55:29 Crofton|work: we need to poke the Yocto AB about this Jan 07 17:55:36 Who is going to do this? Jan 07 17:55:51 kergoth: e-mail michael@yoctoproject.org and I'll help set up. Jan 07 17:56:06 * RP suspects everyone else just took two steps backwards Jan 07 17:56:09 halstead: will do, thanks Jan 07 17:56:22 RP: Crofton|work did agree to raise it with the advisory board earlier when I talked to him, FWIW Jan 07 17:56:31 the bug count issue that is Jan 07 17:56:34 RP: :-) i don't feel i spend enough time in the bugzilla to take lead, but i'd like to help Jan 07 17:57:15 tlwoerner: its more the logisitics of sending out some details of the plan, picking two days, getting buy in from the Yocto AB if possible and so on Jan 07 17:57:36 * JaMa is thinking about "bitbake world" failures scrub Jan 07 17:57:38 I can help with some of it, equally I know what my "free" time is like Jan 07 17:57:41 ok we're 3 minutes from the end; anything anyone wants to discuss before we close? we didn't make it through the whole agenda unfortunately Jan 07 17:57:49 RP: okay, i could organize it Jan 07 17:57:53 bluelightning: what items remain? Jan 07 17:58:14 does anyone thing we need another of these meeting sooner then Feburary? Jan 07 17:58:16 janitorial day/week, initrdscripts/init-live is in very bad contidion, piglit QA issue Jan 07 17:58:16 tlwoerner: help in doing that would be much appreciated Jan 07 17:58:31 JaMa: I think the github mirror name is easy enough to fix, though obviuously it would be a bit disruptive to anybody who's becmome accustomed to the old one. I guess it would be easy enough to keep both around for a while. Jan 07 17:58:42 http://pastebin.com/QvrfH8rp Jan 07 17:58:43 we should have another go at piglit on the mailing list Jan 07 17:58:51 fray: yes Jan 07 17:58:54 RP: I think so too Jan 07 17:59:13 I'm not against another meeting in a week or two weeks..s ince it sounds like we have a lot of other things that could be discussed.. Jan 07 17:59:14 initrdscripts: send patches? Jan 07 17:59:27 pb_: agreed that both should be available for a while, I don't mind shorter name, only in meta-oe/meta-oe combination it's quite confusing Jan 07 17:59:28 fray: I'd be happy with that also... koen? RP? Jan 07 17:59:30 yes, it might be a good idea to have another meeting in say two weeks? Jan 07 17:59:42 JaMa: yeah. I'll sort it out. You might have to remind me later in the week. Jan 07 17:59:48 RP works for me Jan 07 17:59:51 pb_: thanks Jan 07 18:00:21 ok, we're out of time Jan 07 18:00:30 #action raise qt-in-core issue on mailing list Jan 07 18:00:31 pb_: I was thinking about mirroring also -contrib repos, but not sure how many people would find it useful (maybe I'm only one) Jan 07 18:00:37 #endmeeting Jan 07 18:00:37 Meeting ended Tue Jan 7 18:00:37 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) Jan 07 18:00:37 Minutes: oe/2014/oe.2014-01-07-17.03.html Jan 07 18:00:37 Minutes (text): oe/2014/oe.2014-01-07-17.03.txt Jan 07 18:00:37 Log: oe/2014/oe.2014-01-07-17.03.log.html Jan 07 18:00:44 JaMa: sure, no reason not to Jan 07 18:00:57 bluelightning: i can take the qt mailing list action if nobody else wants to (?) Jan 07 18:01:09 tlwoerner: that would be great :) Jan 07 18:01:13 thanks Jan 07 18:01:16 agreed :) Jan 07 18:02:32 hmm they could put actual URLs above... Jan 07 18:02:41 (for the minutes) Jan 07 18:02:51 heh Jan 07 18:02:52 * Xz which agenda point are we on right now? had a nap last 5min... Jan 07 18:03:44 I think we're basically done for this week.. continue on mailing list and in two weeks Jan 07 18:04:19 alright - just wanted to ask about initrd bugfix, who is the maintainer I should directly to ? Jan 07 18:04:28 and I can't find the minutes, they aren't where they're supposed to be :( Jan 07 18:05:02 Xz: it's sgw_ Jan 07 18:05:31 Xz: send them to the openembedded-core ML and I will process them from there. Jan 07 18:05:38 bluelightning: cool, thanks Jan 07 18:05:50 Crofton|work: meetbot's URLs are broken I think... Jan 07 19:25:26 here's some off-topic (but developer-related) humour to lighten your day: http://research.microsoft.com/en-us/people/mickens/thenightwatch.pdf Jan 07 20:25:28 anyone run into an error building with the latest master? eglibc 2.18 giving me a 'No such file or directory' error ... cannot find ....../eglibc/2.18-r0/packages-split/eglibc-thread-db/lib/libthread_db-1.0.so Jan 07 20:25:56 looks like it is building the cross-compiled eglibc when it gives this error Jan 07 20:30:39 apelete: ping Jan 07 20:30:39 there is no libthread_db-1.0.so in that folder ... the file there is libthread_db.so.1 Jan 07 20:31:07 ant_home: hi Jan 07 20:31:15 hello there Jan 07 20:31:48 ant_home: been a while, how are you ? Jan 07 20:32:14 had some free time finally... Jan 07 20:32:25 I was reading about linux-qi Jan 07 20:33:13 about that, could you try to import the defconfig+patches in linux-yocto-dev (3.12)? Jan 07 20:37:21 ant_home: I see there's a linux-yocto-dev.bbappend in meta-handheld Jan 07 20:37:35 what is it exactly, how is it used ? Jan 07 20:37:43 wmcdevel: looks like a mismatch between the filename being packaged and reality Jan 07 20:38:16 although i just built master last night and didn't see that Jan 07 20:38:23 mr_science: just going through the log file ... looks like libthread_db-1.0.so gets renamed to libthread_db.so.1 in the process Jan 07 20:38:52 so that wasn't a hard error? Jan 07 20:39:22 not sure .... it looks like all the .so files go through some rename process Jan 07 20:39:38 apelete: linux-yocto is the preferred kernel but is still 3.10. linux-yocto-dev is up to 3.12 Jan 07 20:40:12 apelete: see this commit: http://tinyurl.com/nsngqhf Jan 07 20:40:52 mr_science: I'm using package_deb as my preferred packaging system Jan 07 20:41:03 mr_science: don't know if that makes a difference or not Jan 07 20:41:07 i just do opkg Jan 07 20:42:07 mr_science: I can give that a try, I guess. I was working with OE from back in 10/2013, and had no build issues. upgraded this morning and *ppppppt* Jan 07 20:42:38 i try to pull at least every couple weeks Jan 07 20:43:46 mr_science: I'm going to try and do a weekly pull once I get the layers for this project finalized; still under heavy dev, and didn't want to add any additional variables to the mix. Jan 07 20:45:05 once your end is "stable" there's probably enough churn to do a nightly pull/build check Jan 07 20:45:52 mr_science: so it seems. the OE community has been very busy :) Jan 07 20:46:02 Jefro, you have minutes Jan 07 20:48:27 unless you'd rather freeze an occasional snapshot... Jan 07 20:49:29 wmcdevel: depending on your goals/requirements, it might make more sense to use an "official" release branch instead of master Jan 07 20:49:54 depends on your depends i guess... Jan 07 20:50:19 mr_science: that's an option, too. like I said, master from like 10/2 was fine for me. Jan 07 20:50:35 do you know off-hand how to pull a particular commit using git? Jan 07 20:50:53 like, by the commit hash id? Jan 07 20:51:02 just checkout the branch and then checkout the commit (make a new branch) Jan 07 20:51:39 er, I guess with gitk would be the easiest way to do that? Jan 07 20:52:01 I can make my way around git, but by no means an expert :) Jan 07 20:52:03 Crofton|work thanks Jan 07 20:52:34 wmcdevel: i use the guis for analysis but not operations Jan 07 20:53:12 literally, you just checkout the commit id you want from a particular branch, which puts you in a "detached head" state Jan 07 20:53:45 you can stay that way if you'll never commit, but it's generally a good idea to make a new branch at that point Jan 07 20:53:48 lol ... there are days when I feel like -I'm- in a detached head state Jan 07 20:54:00 *nods* ok Jan 07 20:54:40 if you do commit in that state, then the commit(s) will not be on a branch Jan 07 20:54:55 they'll be unreachable unless tagged Jan 07 20:55:46 sounds good. Jan 07 20:55:48 so in general, just make a branch from there and you'll be okay Jan 07 20:56:38 ant_home: is linux-yocto-dev the preferred way to add kernel support for a machine in meta-handheld ? Jan 07 20:56:43 i wouldn't use a gui to do anything important either Jan 07 20:57:12 i know several people developers who get into trouble that way Jan 07 20:57:55 mr_science: lol ... generally I don't either. I prefer the command line; don't always have an x session Jan 07 20:58:09 some guis even do their own stupid thing (which works) but makes the history look whacked Jan 07 20:58:51 * mr_science points at some goofy macos tools Jan 07 20:59:49 ha! can't trust those mac types ... still better than windoze, though ;) Jan 07 21:01:34 wtf is a reverse-merge anyway? Jan 07 21:01:59 never seen that in any git documentation... Jan 07 21:02:11 sounds like an "oh s**t" to me Jan 07 21:04:27 ant_home: adding defconfig and patches to linux-yocto-dev looks like duplicating the effort, since ben-nanonote is going to have full upstream kernel support soon anyway (I submitted some patches for the linux kernel, should land in 3.14) Jan 07 21:05:01 ant_home: I may be mistaken though, what is the preferred way to handle this ? Jan 07 21:19:11 mr_science: thankfully, I made note of which particular commit I was working with, so now I'm back on it as its own branch. that's one thing I really like about git - the way it handles branches is so much easier than how svn does it Jan 07 21:20:29 git's pretty powerful but it takes a little bit of a mind-shift just to wrap your head around the basic stuff Jan 07 21:20:52 apelete: consider linux-yocto as upstream Jan 07 21:21:00 i have some code on github that was migrated out of cvs to svn, then eventually to git Jan 07 21:21:54 so true. I'd like to get this place away from subversion, but haven't been able to convince the powers-that-be yet to do so. Jan 07 21:21:57 yay, architecture meeting... Jan 07 21:22:04 apelete: using the .bbappend we get the updates in oe-core as bonus. Less maintainance Jan 07 21:22:25 wmcdevel: you are free to borrow my clue-stick Jan 07 21:22:47 apelete: the idea is to remove legacy kernels from meta-handheld Jan 07 21:22:54 lol Jan 07 21:23:53 the gears of progress roll very slowly here, and sometimes, I think, in reverse Jan 07 21:24:28 apelete: initially it is ok to use a defconfig. However, please process it before with bitbake -c savedefconfig Jan 07 21:48:04 ant_home: ok, I see Jan 07 21:48:15 ant_home: there's quite a lot of patches in the qi-kernel actually (20+ or so), is it okay to go with the linux-qi-ben-nanite recipe for now and then update the recipe to rely on linux-yocto when the patches land upstream ? Jan 07 21:49:34 heh, we are in a similar situation with collie Jan 07 21:58:42 ok, already sent the patches to oe-devel for linux-jlime-ben-nanonote recipe anyway. I'll fix this with the input from the review on oe-devel, not sure how to handle it right now :-/ Jan 07 22:05:33 mr_science: well reverting seems to have it working again. that rename happens in this commit as well, so I wonder if something changed in the order of the packages, or if a regex/glob pattern changed that no longer picks up the file properly. Jan 07 22:19:10 RP, what do you want me to bug the AB about? Advertising the bug hunt? Jan 07 22:19:40 finally reading the meeting notes Jan 07 22:22:28 * darknighte_ wags finger at Crofton|work Jan 07 22:22:37 Crofton|work: to allow their employees some time for bug fixing in the sprint Jan 07 22:22:44 yep Jan 07 22:22:59 I went to see a movie this afternoon Jan 07 22:23:09 I think I was one of 3 males over 18 in the audience Jan 07 22:23:27 Crofton|work: what movie? Jan 07 22:23:33 Frozen Jan 07 22:23:53 heh. Jan 07 22:23:56 the artic Vortex is here and they had a matinee since school was out Jan 07 22:24:16 fun! Jan 07 22:24:36 i saw it with the kids over the xmas break. it was the first movie that I've taken mine to. Jan 07 22:25:20 any movie where trolls raise the hero is OK with me Jan 07 22:25:47 rp I need a better word than allow :) Jan 07 22:25:57 I think I will go for encourage Jan 07 22:26:06 as opposed to "force" Jan 07 22:27:42 Crofton|work: that works :) Jan 07 22:29:11 wording is everything Jan 07 22:29:55 the weekend versus weekday question is interesting Jan 07 22:30:13 as more people get day jobs, I feel the weekdays work better Jan 07 22:32:20 Jefro, when is the next AB meeting? **** ENDING LOGGING AT Wed Jan 08 02:59:59 2014