**** BEGIN LOGGING AT Tue May 13 02:59:59 2014 May 13 03:07:26 akbennett: clone oe-core then cd oe-core; . ./oe-init-build-env; bitbake qemu-helper-native meta-ide-support;runqemu qemuarm nographic May 13 07:00:05 good morning May 13 07:20:24 RP: how do RRECOMMENDS work for *-replacement-native recipes? May 13 07:20:58 RP: git needs ca-certs to work with https://, which are in RRECOMMENDS_libcurl May 13 07:21:20 koen: its not seeing that dependency? May 13 07:21:21 but building git-replacement-native doesn't install ca-certs into sysroot May 13 07:22:47 koen: I have a suspicion that since we set PACKAGES to "", native recipes haven't been seeing their R* depends :/ May 13 07:23:27 I wish git-send-email wasn't written in perl May 13 07:23:37 then I could just forget making git-perltools work May 13 07:24:39 RP: would adding ca-carts to DEPENDS in curl.bb with a comment explaining why be acceptable as short term fix? May 13 07:24:56 koen: a DEPENDS_append_class-native would be ok May 13 07:25:14 koen: well, make it an RDEPENDS May 13 07:31:08 RDEPENDS works for -native? May 13 07:31:47 if so, my commit message and comment are bogus :) May 13 07:33:33 koen: RDEPENDS_ probably doesn't since PACKAGES="" however RDEPENDS probably does May 13 08:35:11 morning all May 13 08:38:10 koen: I think we need to file a bug about this issue but I've tried locally and its not something we can fix easily :( May 13 08:41:34 gm bluelightning, all May 13 08:42:06 koen: Filed as https://bugzilla.yoctoproject.org/show_bug.cgi?id=6317 May 13 08:42:55 thanks May 13 09:27:10 RP: more bad news: we probably need to run postinsts for some -native* packages May 13 09:28:12 koen: they probably need something adding specifically around sstate rather than the postinst May 13 09:29:21 koen: pixbufcache.bbclass does that for example May 13 09:29:34 I'll have a look at ca-certs after lunch May 13 09:31:24 koen: you may be able to copy the class-nativesdk do_install_append for that May 13 09:45:54 hi bluelightning May 13 09:48:34 which recipe should now provide libgcc*so*? May 13 10:17:40 RP: patch for ca-certs sent May 13 10:17:59 RP: what command did you run to make git-native fail with perl enabled? May 13 10:24:55 koen: I think it was in Saul's email? May 13 10:26:33 hi woglinde May 13 10:42:27 RP: git-difftool May 13 10:42:38 RP: but I want to know the highlevel command that triggered it May 13 10:43:19 koen: I think Saul just picked one one of the perl binaries May 13 10:43:24 er, scripts May 13 10:45:09 are they supposed to work without using some perl-native wrapper? May 13 11:43:26 ok, sorry to bother you all with this issue but it is really driving me nuts. I am struggling with OpenGL SW emulation (mesa) with virtual frame buffer on ARM device. It all worked fine couple of months ago with Yocto danny branch stuff using xserver 1.11.2 and mesa-dri/mesa-demos in IMAGE_INSTALL. It seems that I am missing something or something is misconfigured. For example, "glxinfo" gives me: "Error: couldn't find RGB GLX visual or fbconfig". May 13 11:44:30 I found out that there has been a related bug in Ubuntu at some point but not sure if it has anything to do with this one. May 13 11:44:49 muppe hm do you need the fullblown gl or would be egl enough? May 13 11:45:20 I think we had a fullblown version that worked earlier. May 13 11:45:37 in distro features I have "opengl" May 13 11:45:49 and x11 May 13 12:16:54 woglinde: I have Xvfb working as it should (I can open xterm and see it on a VNC client) but OpenGL stuff is not working May 13 12:45:40 muppe hm sorry I have no idea May 13 12:45:51 ok May 13 13:04:56 muppe maybee the danny branch is too old May 13 13:05:01 try with dora May 13 13:05:43 muppe btw. why you need really opengl it should be really slow in arm sw May 13 13:12:25 woglinde: it worked on Danny but after updating to Dylan it stopped working. May 13 13:13:02 I need OpenGL because of Qt quick May 13 13:13:36 OpenGL + Xvfb is a temp solution but it would still be nice to get it working. May 13 13:24:24 muppe hm hm May 13 13:24:43 muppe because you are sticked to qt4 instead of qt5 with egl support? May 13 13:25:13 I am using qt5.1.1 but not the very latest 5.2 May 13 13:25:38 that was also the case with the danny stuff I used earlier. May 13 13:29:17 what arm platform you are using? May 13 13:29:25 I would try egl hw support May 13 13:29:42 instead of full gl support in sw May 13 13:30:05 I don't have a GPU on the device. Need to use SW emulation. May 13 13:30:24 oh okay May 13 13:30:27 strange device May 13 13:30:45 :) May 13 13:31:10 sorry then, I have no idea how fbdriver and gl works together May 13 13:31:16 till later maybee May 13 13:31:27 ok, thanks anyway. May 13 13:40:19 Hi! Does DISTRO affect the sstate checksums? I.e. will the same recipe if used in different DISTROs be recompiled for each distro? And where can I find out about these things? I had a quick look at sstatesig.py but am no python expert and it doesn't seem straight forward to figure out what exactly counts as input to the sstate has generator May 13 13:42:42 andre_d: it likely will yes May 13 13:43:15 andre_d: you can use bitbake-dumpsig and bitbake-diffsigs to inspect and compare signatures May 13 13:44:08 (.sigdata files in tmp/stamps) May 13 13:46:09 bluelightning: thanks! May 13 14:25:47 hi, quick question May 13 14:25:57 The text of a license changed May 13 14:26:16 but using bitbake -c clean foo then bitbake foo May 13 14:26:37 I'm still getting the old text in ./tmp/deploy/licenses/foo/ May 13 14:27:25 is that possible to force it to take the new one without cleaning tmp ans sstate-cache ? May 13 14:29:41 abelloni: I'm pretty sure that text comes from the generic license that matches up with the LICENSE value, rather than the source May 13 14:31:46 yes it is May 13 14:31:55 that is eactly the text that changed May 13 14:31:59 exactly May 13 14:32:23 I have a bunch of licenses in a folder of my layer May 13 14:32:56 I've added LICENSE_PATH += "${LAYERDIR}/licenses" to my layer.conf May 13 14:37:42 abelloni: so it's the do_populate_lic task for the recipe that does the copy, if you force that to run again (bitbake -c populate_lic -f recipename) then it will run it again May 13 14:38:27 bluelightning do we have some generic mechanism to disable certain tty's for systemd? May 13 14:38:50 woglinde: I think we might do yes, I don't know it off the top of my head May 13 14:39:10 koen, in the rrd patch, you use the broken auto sepo class and change some S to B's May 13 14:39:18 does that mean you tried and fialed to fix it? May 13 14:39:30 yes May 13 14:39:51 I wasn't sure if I should keep it completely broken and use the class or fix it up a bit and use the class May 13 14:40:26 bl hm okay May 13 14:40:40 bluelightning: exactly what I was looking for, thanks ! May 13 14:40:52 because system inspect the kernel cmdline and uses the console in there May 13 15:07:21 hm hm how to prevent systemd to logging to the serial console May 13 15:17:06 woglinde: cmdline changes May 13 15:18:08 warheadsse hmhm yes I read it May 13 15:18:35 WarheadsSE the problem is to let systemd not log to a specfic console May 13 15:19:27 define 'log' May 13 15:19:34 you mean 'output messages' May 13 15:19:42 or 'point journalctl to it' ? May 13 15:20:01 koen now it comes tricky we dont use journal May 13 15:20:14 so you don't really mean 'log' May 13 15:20:15 plain old busybox-syslog May 13 15:20:23 the systemd log May 13 15:20:26 yes sorry May 13 15:20:46 add 'quiet' to your cmdline, that should make most of it go away May 13 15:20:56 if not, rework your console= bits May 13 15:21:32 to make it more complicate kernel log would be okay May 13 15:22:11 Well, if you are using systemd.. you're using journald, you're just not using it for *storage* May 13 15:22:39 WarheadsSE haha nope you can complete disable journald and use only syslog May 13 15:23:04 mm, I suppose if you disabled it entirely from the systemd recipe May 13 15:23:05 WarheadsSE but systemd greps the console from kernel cmdline and pushes stuff there May 13 15:23:17 Yeah: quiet. May 13 15:23:58 but looks like systemd is to unflexibel in this way May 13 15:24:23 sysv did the same May 13 15:24:28 output to the bits in console= May 13 15:25:59 hm so lets hope disabling the getty on the serial is enough for not crashing the machine May 13 15:43:00 Yeah, you might see some open on that May 13 15:43:50 Since systemd will likely detect @ start a getty @ console= May 13 16:03:01 * fray is here.. May 13 16:04:06 * RP is here May 13 16:04:36 isn't it early? May 13 16:04:51 OHHH the meeting was moved.. May 13 16:04:56 duh, I didn't look at my calendar today May 13 16:05:01 the calendar invite says it's not for another 2 hrs May 13 16:05:10 Yes.. I'm 2 hours early.. :) May 13 16:06:25 oh, I see :/ May 13 16:24:42 What is the recommended way to do a quick kernel rebuild, repackage and image generation after adding a driver or otherwise making a small edit to the .config file? If I up the priorities, I get a whole new 3 hour build, and if I don't I can't seem to get new kernels or new images. May 13 16:25:47 jkelly bitake -c cleansstate linux or maybe linux-something_else depending on the machine May 13 16:25:52 bitbake linux May 13 16:26:59 Thanks---I'll give it a try. May 13 16:27:31 jkelly are using the standard yocto kernel? May 13 16:30:41 It looks like it is kernel.org May 13 16:34:58 RP: Hi, lost patch http://lists.openembedded.org/pipermail/openembedded-core/2014-May/092329.html May 13 17:50:23 tsc today? May 13 17:54:56 koen: yep, in ~5 mins May 13 17:58:26 hi guys May 13 17:58:29 I am here May 13 17:59:47 I'm here May 13 17:59:54 * RP is here May 13 18:00:05 fray: you around as well? May 13 18:03:15 so I don't think we have an agenda, but there were a bunch of suggestions in Jefro's email May 13 18:03:39 basically further discussion on things that came out of OEDAM May 13 18:04:17 * fray is here.. May 13 18:04:24 sorry got delayed on something else May 13 18:04:37 I agree, going over the OEDAM is likely the best topic for today May 13 18:05:09 hi jefro__ May 13 18:05:45 so we're currently starting the public OE TSC / Workgroup meeting in case anyone's wondering what's going on ;) May 13 18:05:51 all are welcome to participate May 13 18:05:57 Blue lightning hiya May 13 18:06:00 FYI -- http://openembedded.org/wiki/OEDAM#Minutes May 13 18:06:40 ok, so does someone want to chair? May 13 18:07:02 * fray fails to step back... May 13 18:07:03 I can May 13 18:07:06 go for it :) May 13 18:07:29 ok.. so first topic then is the OEDAM meeting minutes.. any other topics? May 13 18:07:57 * RP may as well give the headsup here, I'm thinking of trying to kill off binconfig.bbclass where we can, basically deleting -config scripts from recipes one by one. I'll put a proper proposal to the list in due course but OE-Core at least looks relatively clean for it. This will include patching in pkgconfig into software the upstreams don't seem to want patches May 13 18:09:11 RP should we discuss that, or just a heads up? May 13 18:09:35 fray: just a headsup unless anyone has something they particularly want to add May 13 18:09:46 binconfig.bbclass is already rewriting most of the -config bits anyway May 13 18:10:18 koen: right, there are just a load I think we can kill off now entirely, enough of the world is using pkgconfig May 13 18:10:19 my only concern is simply falling back to the host and introducing host contamination by calling those scripts instead.. May 13 18:10:41 fray: thankfully the linker complains extremely loudly about that :) May 13 18:10:42 otherwise I think directly suing pkgconfig makes way more sense then effectively wrapping it May 13 18:10:55 RP, "your welcome" ;) May 13 18:11:21 That sounds like a good janitorial-type task. It has to be dealt with on a case-by-case basis, and is likely not a huge priority. May 13 18:11:52 Ohh I frogot.. is someone logging the discussion for notes? May 13 18:12:27 kergoth: I had a go at fixing the OE-Core recipes and it causes a surprising amount of head scratching but I'm allergic to m4 ;-) May 13 18:12:28 the bot isn't here, but I don't think we'll have trouble finding logs May 13 18:12:48 of someone could just send a capture to me afterward I'll post to the ml May 13 18:12:50 m4 quoting is the devil May 13 18:12:55 top two of http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=rpurdie/t222 if anyone is interested May 13 18:12:57 jefro__: I'll take that AR May 13 18:12:58 do i need 3 [] here or 4? May 13 18:13:35 kergoth: I fell for the pkg-config in an if statement trap May 13 18:13:59 :) May 13 18:14:06 Ok.. anything else on that, or should we move on to OEDAM? May 13 18:14:13 move on May 13 18:14:22 ok.. then.. May 13 18:14:24 again the URL: May 13 18:14:27 http://openembedded.org/wiki/OEDAM#Minutes May 13 18:14:41 we encourage people to read what was discussed and ask questions, either here or on the mailing list.. May 13 18:15:15 * RP would like to mention that we are in serious need of help with the developer experience and workflow part May 13 18:15:20 RP, bluelightning, others how should we go over this.. I know we want to cover the 'usage' documentation item.. anything else explicitly? (perhaps the meta-openembedded maintainers) May 13 18:15:41 The system works well for a subset of people but not all users and I think for OE to move further, that needs to be addressed May 13 18:15:56 We havent yet cleaned up S != B May 13 18:16:15 for lava: we just had a reorg in linaro that split the lava team into a product team and a lab team, which should improve the development process May 13 18:16:48 lets just go in order of the notes then.. May 13 18:16:51 Lava... May 13 18:17:00 for those who don't know this is a test infrastructure that Linaro is using.. May 13 18:17:00 khem: today I fixed all the S!=B issues we hit in the linaro autobuilder, May 13 18:17:16 there has been put forth the idea to use it to help test OpenEmbedded.. May 13 18:17:34 I'm still puzzled about this "2k tests in 1.6" - we don't have 2000 tests May 13 18:17:45 so some early work has been done to try to automatically boot and kick off tests.. May 13 18:17:46 RP: some way of integrating Eclipse and toaster May 13 18:17:59 thinking of hardcore developers say QT guys May 13 18:18:03 bluelightning: grep ptest | wc -l? May 13 18:18:07 they want to use QT Creator May 13 18:18:09 bluelightning it's Linaro that has 2k tests from what I understand.. I know we don't.. unless you could each test in same ltp, or posix.. or... May 13 18:18:34 Linaro either has way more or way less than 2k tests depending on what you're counting. May 13 18:18:41 fray: I guess we should clarify what is meant there May 13 18:19:11 so for the lava work, it was decided (and some folks volunteered) to help connect the autobuilder output to the lava environment.. help get some reference system (singular) booting and some type of testing working as a proof of concept.. May 13 18:19:15 after that we'll see where it goes.. May 13 18:20:58 ok.. so someone should clarify the 2k tests in the notes (or just remove the 2k number).. the key is porting tests takes resources.. ones that have not volunteered at this point.. :) May 13 18:21:10 but we're getting to a proof of concept that this is something useful.. May 13 18:21:19 fray: what is meant by porting tests though? May 13 18:21:38 making them run in the lava environment.. which may require work in lava, or oe.. May 13 18:21:58 As I understand lava is able to launch ptests May 13 18:22:08 shouldn't be hard to write a bbclass that generates the json and yaml for it May 13 18:22:12 as long as it prints pass/fail May 13 18:22:37 thats the next step.. but someone has to do the work.. and at present I don't think anyone has volunteered.. May 13 18:22:53 so from that statement, I think we need to ask for people who are interested to talk with us.. May 13 18:23:06 The 2k number was mentioned at oedam, I thought it referred to linaro test cases May 13 18:23:11 fray: join the mailing list May 13 18:24:05 RP, exactly.. which list do we point people toward for this? May 13 18:24:32 fray: the automated-testing@yoctoproject.org one May 13 18:24:41 ok.. May 13 18:24:43 https://lists.yoctoproject.org/listinfo/automated-testing May 13 18:24:54 I'm going to move to the next topic in the interest of time.. May 13 18:24:58 Ongoing role of the TSC.. May 13 18:25:00 jefro__: this isn't on https://www.yoctoproject.org/tools-resources/community/mailing-lists May 13 18:25:05 quick summary: May 13 18:25:26 hmm, I'll fix May 13 18:25:38 We continue to pose the question if the TSC is still needed, are these open meetings useful, etc. General concensus at the OEDAM is the TSC is still useful and people like the open meetings.. May 13 18:26:19 Some concerns have been raised (off list, and not during OEDAM) about the membership of the TSC being heavily "Yocto Project" or Intel or corporate biased.. the feedback from those present is that we're doing a good job seperating our TSC role from that of our employer.. May 13 18:26:31 with that said, if anyone sees it differently please call us on it.. May 13 18:26:58 Future actions, the board is going to ask to see if anyone wants to join the TSC (May?) May 13 18:27:18 if not, there will be a general revote of the existing slate, otherwise a more general elections will take part.. May 13 18:27:27 Something we should check with the TSC people: Are we all happy continuing? May 13 18:27:38 Yes.. May 13 18:27:46 I'm happy May 13 18:27:55 * RP is ok May 13 18:27:57 I'm going to step down at the next election May 13 18:28:03 For those that were present we all I believe indicated we were find with continuing on.. (speaking for myself I am, but if someone more qualified comes along, I'm willing to step down).. May 13 18:28:23 koen, ok.. so we will want someone new to step in for your current role.. May 13 18:28:39 I think Martin did say he might be willing to step up if someone wanted to step down May 13 18:28:48 if more then one person wants to step forward, we'll certainly entertain that as well.. May 13 18:28:59 although it was hard to tell over the phone :) May 13 18:29:34 he said he was interested, but didn't feel the need to replace any existing member.. (I'm sure I'm paraphrasing.... and he can correct the record if we're incorrect) May 13 18:30:18 We should let the board know and let them take it from there May 13 18:30:26 final thing that was mentioned, somewhat as an aside to this process.. the board is creating a mock budget, and will be soliciting donations in the future.. for things like infrastructure costs, stickers (trade shows), and paying for travel to places like FOSDEM.. May 13 18:30:43 RP, yes.. so action item.. Koen will be stepping down at next election.. May 13 18:30:56 RP, will you (or Koen?) send that note to Phillip? May 13 18:31:49 fray: I can May 13 18:32:34 ok.. then on to the next (IMHO most important) item.. the "Why is embedded still hard?" topic May 13 18:32:54 this really revolved around best practices, learning curve, and how to continue to improve what we have.. May 13 18:33:01 fray: depends on who is asking that question May 13 18:33:26 one of the things that we are asking people, we want to come up with a lists of tasks (use-cases) that people need to do with the system, and then ask folks to document their own person workflows.. May 13 18:33:30 I think that is part of the problem since the answer depends on that users expectations and requirements May 13 18:33:50 we then have some people who want to agregate that into either a best practices -- or into a list of things we need to improve.. (likely both) :) May 13 18:34:10 RP, exactly.. user expectations, requirements are huge here.. and we all only know of our own subset.. May 13 18:35:09 (jumping is as I've been lurking) - i've got a bunch of updated workflow scripts i can publish along with a few notes, remind me to do that if i forget! May 13 18:35:24 paulbarker: that would be great! May 13 18:35:47 yes.. that would be good.. May 13 18:35:52 joaohfreitas: merged FYI, thanks May 13 18:36:09 paulbarker: that sounds extremely useful, please do! May 13 18:36:38 Anyone have anything else to add to the workflow discussion? much of the notes are our overall brain storming and talking.. but the discrete action is to ask people to tell us what they do with OE, and then how they do it.. May 13 18:37:07 i've put it on my todo list now so i shouldn't forget May 13 18:37:17 "app developers don't care" - I think that needs expanding May 13 18:37:39 ahh.. app developers don't (or shouldn't) care about using all of bitbake/oe May 13 18:37:47 right, that was my assumption May 13 18:37:58 they should care about compiling, debugging, and even deployment of their application May 13 18:38:03 but it shouldn't be taken to mean there's nothing we can do for them ;) May 13 18:38:13 correct.. I'll edit that and expand.. May 13 18:38:17 thanks May 13 18:39:35 I think the important thing at this point is we need to take a bit of a step back and work out what needs doing May 13 18:40:13 yes.. May 13 18:40:13 it would be easy for us to think of areas where we know things could be improved and only touch those bits, with issues from people like app developers remaining unadressed May 13 18:41:05 so again the request is for people to tell us what workflows they use, how they get things done.. and then eventually document the actual steps.. May 13 18:41:24 to clarify the document steps is very much a bullet list of I do this, then this, then this, then this...... May 13 18:41:43 the trouble is some of those people aren't really well-represented in our community, so I think it would really help if people could gather feedback from them within their own organisations (or encourage them to submit feedback) May 13 18:42:05 yes May 13 18:42:17 should we move to the next topic? May 13 18:42:23 I think so yep May 13 18:42:26 increasing layer quality... May 13 18:42:53 the key thing here is that each layer should have a maintainer file, with maintainers that reply.. if that doesn't happen.. then we should work to find replacements.. May 13 18:43:05 (that specifically goes with OpenEmbedded layers).. May 13 18:43:09 A README file May 13 18:43:10 we should set an example for non OE layers.. May 13 18:43:16 yes.. README.. sorry.. May 13 18:43:29 so May 13 18:43:38 view is maintainership == quality.. (or at least an initial view of quality) May 13 18:43:43 the README can point at a maintainers file May 13 18:43:45 what can we do about layers that violate policies and/or good practices? May 13 18:44:03 if they're within the OE family (or YP) then we should work to get them corrected.. May 13 18:44:06 e.g. meta-freescale breaks heavily because they poke at the armhf tunes May 13 18:44:12 koen: do you have a proposal and some specific examples of issues? May 13 18:44:24 outside, there isn't much we can do -- but it's a good thing if we can document what problems are common and suggest alternatives.. May 13 18:44:30 the intel emgd layers set preferred versions in the machine file May 13 18:44:33 etc May 13 18:45:12 koen: with those two being Yocto Project compatible, I'd suggest the first thing to do is flag the issues to them May 13 18:45:18 I did May 13 18:45:27 koen: are there open bugs? May 13 18:45:40 maybe some sort of layer lint tool (e.g. incorporating kergoth's leaky-layer script above) where the results get linked / reported out on the layer index would help? May 13 18:45:45 otavios response was basically "that's your opinion" May 13 18:45:53 s/above/discussed in #yocto/ May 13 18:46:21 this again is where the concept of file good and bad examples and lets trying to use them as best practices comes into play May 13 18:46:29 koen: as I said earlier if we have no documentation on that kind of policy we can't expect everyone to abide by it May 13 18:47:01 if there's contention, that's what we (the TSC) are supposed to be here to help resolve May 13 18:47:08 koen: I think with Yocto Project Compatible things there are ways we can raise these discussions. The next step would be to open a bug and ensure I know about the issue May 13 18:47:18 RP: I'm close to killfiling yocto bugzilla things May 13 18:47:21 too much spam May 13 18:47:33 like that intel dude with comics sans in his sig May 13 18:47:50 koen: I don't see that, I use text only ;) May 13 18:48:17 koen: he is trying to help get various old bugs cleaned up so his intentions are good at least May 13 18:48:46 koen: if its getting too much, perhaps let him know that May 13 18:48:53 after some reorg a lot of bugs were tagged NEEDINFO because the new guys didn't bother to read the bugs May 13 18:49:14 koen: May 13 18:49:30 these are linaro bugs or yp May 13 18:49:36 koen: Give me a list of the bugs and I can look into those May 13 18:49:42 so at this point bugzilla only annoys the crap out of me May 13 18:49:57 RP: one is the infamous kiosk mode for hob :) May 13 18:50:17 koen: well, we can probably get you out of the cc of things you don't care about any longer May 13 18:50:34 koen: it doesn't change the fact that the bugzilla is a good tool to try and resolve the issues you've mentioned with those layers May 13 18:50:41 koen: be that as it may, it is the mechanism we have for tracking issues, and it's best to have them filed or they will likely get forgotten May 13 18:51:02 I guess I'm holding it wrong then May 13 18:51:39 koen: maybe you should think less of it bugging you and more of it bugging the people who are supposed to be fixing the issues ;) May 13 18:51:49 it does work both ways :) May 13 18:52:26 that reminds me May 13 18:52:28 koen: seriously, I do watch nearly all the bugs in there at some point and this is the first I've heard of the emgd version issue in meta-intel May 13 18:52:43 koen: I think that can be fixed relatively simply too May 13 18:52:47 if someone mentions a git hash in a commit, can we at least try to make it an OE git hash instead of a poky one? May 13 18:53:19 7 minutes to the hour.. May 13 18:53:26 I can only speak for myself and say I always do that... May 13 18:53:43 RP: sure, drop the PREFERRED_VERSIONs from the machine.conf and document them in the README May 13 18:53:43 koen: short of me checking every single commit, I'm not sure how we'll enforce that :/ May 13 18:53:54 in the YP bugzilla though, poky revisions are used unless noted otherwise May 13 18:54:03 koen: and break the EMGD builds on the autobuilder? Sure. May 13 18:54:06 RP: it would help to refuse pulls based on poky git May 13 18:54:09 RP we could have pre commit hooks.. but I'm not sure it's wroth it May 13 18:55:01 RP: I've looked at emgd heavily the past few weeks and it was broken for a long time in 'dora' May 13 18:55:03 koen: I suspect it would help you and cause pain for a significant number of others May 13 18:55:22 due to linux-yocto problems not pulling in the emgd branch thing May 13 18:55:54 so I'm not sure if it's actually working in master May 13 18:55:57 koen: That doesn't change what I said above May 13 18:56:20 koen: if it isn't working in master then that is bad. It doesn't mean intentionally breaking it is right May 13 18:56:37 as long as there are no SHA cross-references I think pulls might be ok May 13 18:56:40 so what's the process of making it 'official' that MACHINE.confs are forbidden to set DISTRO vars? May 13 18:57:01 We need a set of layer guidelines May 13 18:57:25 the Yocto Project Compatible ones are probably a start and I'd like to try and extend those a little soon May 13 18:57:28 Wouldn't careful use of DEFAULT_PREFERENCE / COMPATIBLE_MACHINE be an alternative to the version preferences in the machine, where appropriate? May 13 18:57:38 to include things like checksum changes with addition of BSP layers May 13 18:57:53 we need to also help inform people what are distro vars, what are machine, etc.. thats not something that I've seen well captured.. partially because we were waiting for a large enough ecosystem on layers to help dictate what we need to specify May 13 18:57:59 kergoth: yes, but not in the BSP layers May 13 18:57:59 (IMHO we're there now..) May 13 18:58:12 kergoth: yes, there are some ways to fix that, not least that emgd uses a spealist machine arch these days May 13 18:58:31 the long of the process I think is: document policies -> agree on them -> write tools to verify they are being followed -> report on layers following them or not May 13 18:58:32 its just a quesiton of ensuring those versions are only enabled with that arch code May 13 18:58:44 we're at step 1 - document policies May 13 18:58:48 koen: bsp layer is appropriate if the thing really isn't buildable for a given machine, or is broken for it. it should be marked as skipped for such a case May 13 18:59:06 so I'd suggest we take step 1 to the list(s) and get feedback on what policies, for layers, need to be put in place.. May 13 18:59:17 koen: I'm going to disagree slightly and say that some policy in there is ok, as long as its isolated to specific machines in a distro compatible way May 13 18:59:23 fray: I have opened a bug on variable classification in the docs, FYI May 13 18:59:25 kergoth: meta-ti has an anoymymous method that says "the GL driver is hardfloat, won't work" at parse time May 13 18:59:29 ok May 13 18:59:53 koen: so can we *please* start collecting bugs on these issues May 13 19:00:16 kergoth: there are situations where you don't case about certain drivers (or refuse to support them) and don't want the BSP to poke at things May 13 19:00:17 koen: it will not change overnight but as we spread awareness, it will get fixed May 13 19:01:16 s/case/care/ May 13 19:02:12 ok we're 2 minutes after at this point.. May 13 19:02:38 I'd suggest we call the meeting over.. and move further discussion to the channel (outside of the TSC) or to the mailing list.. May 13 19:03:01 * RP can stick around a bit longer but I agree May 13 19:03:02 as for the remaining items from the OEDAM.. I think they're more future looking so they may not really need to be discussed, but we could cover them in the next regularly scheduled meeting (next month) May 13 19:04:26 ok meeting over for today, any objections? May 13 19:04:36 nope May 13 19:04:39 fray: not from me May 13 19:04:43 ok with me May 13 19:05:09 we have concensus (unless khem objects) :) May 13 19:05:20 adjourn May 13 19:05:25 Thanks everyone May 13 19:06:00 koen: emgd is not ported to v3.14 kernel May 13 19:06:26 all the BSPs using EMGD driver are currently at v3.10 linux yocto kernel May 13 19:07:16 koen: and these work fine with current meta-intel master with daisy/master poky/oecore May 13 19:07:25 jefro__: log is in your email btw May 13 19:08:41 nitink: it's about PREFERRED_VERSION_xorgstuff May 13 19:09:17 koen: Is that an issue if its put into an emgd specific package architecture? May 13 19:09:27 bluelightning got it, thanks! May 13 19:09:57 RP: kinda sorta May 13 19:10:27 RP: it's locked at an xorg version that is incompatible with most of the x stuff in OE May 13 19:10:42 koen: ok, so that is a different issue :/ May 13 19:11:15 and since it has pcie and usb, that is *($*(@@ annnoying May 13 19:11:19 koen: and its not something that is any of our control (not nitink's or anyone we know) May 13 19:11:56 koen: but this isn't like the machine is forcing other things to that version so I don't think this violates any layer guidelines May 13 19:12:25 koen: trying to enforce a layer guideline to change the emgd binaries simply isn't going to go anywhere May 13 19:12:50 and I say this as someone who prior to Yocto worked on the Poulsbo graphics driver at Intel :/ May 13 19:13:53 RP, I'm not following closely, but we need to make sure that you can use multiple BSPS in one build May 13 19:15:14 Crofton|work: due to some hard work in meta-intel you can, you can even build emgd and non-emgd versions of those machines May 13 19:15:16 RP: the emgd arch made is less annoying, but it still is distro policy May 13 19:15:56 at any rate, we need to get this stuff down so BSP creators know where they will get pushback May 13 19:15:57 koen: I do not see any way around this other than simply not shipping them at all May 13 19:16:33 koen: seriously, I did my best to help things with the emgd arch stuff. I cannot see anything more that can be done but proposals would be welcome May 13 19:17:04 RP: so 'emgd' is special and allowed to break rules, fine May 13 19:17:10 document that in the README May 13 19:17:24 koen: It is not breaking "THE RULES" May 13 19:18:03 preferred_version is distro territory, except for kernel and bootloader May 13 19:18:24 harware vendor makes our life hard, news at 11 May 13 19:18:36 koen: I disagree in this case specifically because they've setup an arch specific feed May 13 19:18:46 koen: I need to step afk. If the emgd machines bother you don't use them May 13 20:54:10 is gstreamer-0.10 support dropped from QT5.3+ upstream May 14 02:06:22 Hi, I am building pulseaudio package for raspberry pi. My package is not getting shipped to rootfs. Do I need to update any bb file? thanks **** ENDING LOGGING AT Wed May 14 02:59:59 2014