**** BEGIN LOGGING AT Tue Dec 30 02:59:58 2014 Dec 30 09:03:01 morning all Dec 30 09:08:09 bluelightning: don't show https://communities.intel.com/servlet/JiveServlet/downloadBody/23159-102-6-27859/edison-bsp_ug_331188-003.pdf to Tracey Dec 30 09:08:15 she'll have an aneurism Dec 30 09:42:33 hello all. Are there any people involved in meta-qt5 recipes in the area ? Dec 30 09:49:31 otavio: ping Dec 30 09:54:42 JaMa: ping too :) Dec 30 10:02:13 pong Dec 30 10:07:02 JaMa: hi, I'm performing some tests with Qt 5.4.0 release from December, especially with QtWebKity Dec 30 10:08:26 JaMa, a crash occurs when using oe recipes because of this commit in QtWebKit : https://qt.gitorious.org/qt/qtwebkit/commit/34d4628b981add039a9a349723cbdff1dadca144 Dec 30 10:09:24 JaMa: with oe recipes, my QMAKE_COMPILER is mipsel-linux-uclibc-gcc, which is added in CONFIG variable Dec 30 10:09:38 whereas this commit expects to have "gcc" in CONFIG variable Dec 30 10:10:13 have you tried to report it upstream? Dec 30 10:10:52 urgh, Qt and triplet handling :-( Dec 30 10:11:35 JaMa: I think the issue comes from oe recipe Dec 30 10:11:44 JaMa: according to this file in qtbase: https://qt.gitorious.org/qt/qtbase/source/68676d2128e86bbe5c650b8be7f8b78cb7f60e8f:mkspecs/features/spec_post.prf Dec 30 10:11:59 JaMa: "gcc" should be defined, for all *g++* configs Dec 30 10:14:03 JaMa: as QMAKE_COMPILER is already defined in linux-oe-g++/qmake.conf, gcc is not added in my Yocto build Dec 30 10:14:29 see OE_QMAKE_COMPILER Dec 30 10:14:34 https://github.com/meta-qt5/qtbase/commit/7a4203ad784f253e25f34d4cd32ccf2730738b44 Dec 30 10:15:10 exactly yes Dec 30 10:15:24 classes/qmake5_base.bbclass OE_QMAKE_COMPILER = "${CC}" Dec 30 10:15:42 maybe it's not needed anymore, please test and send patch if it helps to remove it Dec 30 10:15:45 to fix the issue, I'd add gcc in the following line of qmake.conf Dec 30 10:15:50 QMAKE_COMPILER = $(OE_QMAKE_COMPILER) Dec 30 10:16:08 https://www.irccloud.com/pastebin/lWyi4xxQ Dec 30 10:16:36 but I'd like to have your opinion Dec 30 10:16:54 (I'm performing a full build to test it right now) Dec 30 10:17:24 also, just removing the line should work too Dec 30 10:42:53 JaMa, ottavio: here's a proper fix for me : https://github.com/jbrianceau/meta-qt5/commit/b70ff8bfd04adcaaa582d3b1a175d8e78c25b972 Dec 30 10:48:23 JaMa: what's the best way to submit it for review ? Should I create a pull request ? Dec 30 10:49:33 jbrianceau: follow the README file and send it to ML Dec 30 10:52:28 JaMa: will do, thanks! Dec 30 11:45:36 jbrianceau_brb: hi Dec 30 13:03:14 otavio: hi Dec 30 13:30:28 jbrianceau: how are you doing? Dec 30 13:31:05 otavio: fine and you? Dec 30 13:31:16 jbrianceau: great as well Dec 30 13:34:30 otavio: Do you have time to review the patch I sent ? Please feel free to ask if you need details about it Dec 30 13:34:46 jbrianceau: which one? Dec 30 13:35:08 otavio: [meta-qt5][PATCH] qtbase: Add gcc to QMAKE_COMPILER variable. Dec 30 13:35:42 otavio: sent on the mailing list, as JaMa told me, and also available here : Dec 30 13:35:50 https://github.com/jbrianceau/meta-qt5/commit/b70ff8bfd04adcaaa582d3b1a175d8e78c25b972 Dec 30 13:37:11 jbrianceau: so you are adding two compilers as option? Dec 30 13:37:16 Is that the idea? Dec 30 13:38:20 otavio: yes, it's possible to have multiple entries in it, as in https://qt.gitorious.org/qt/qtbase/source/68676d2128e86bbe5c650b8be7f8b78cb7f60e8f:mkspecs/features/spec_post.prf Dec 30 13:39:03 jbrianceau: but I don't think gcc should be the one. Shouldn't CC be the one? Dec 30 13:39:39 otavio: for me, CC is mandatory here because "linux-oe-g++" does not reflect the target architecture Dec 30 13:40:19 otavio: however, as you can see in https://qt.gitorious.org/qt/qtbase/source/68676d2128e86bbe5c650b8be7f8b78cb7f60e8f:mkspecs/features/spec_post.prf, *g++* platforms expect to have "gcc" in QMAKE_COMPILER Dec 30 13:40:48 otavio: I discovered this by switching from Qt v5.3.2 to Qt v5.4.0 in Yocto Dec 30 13:41:29 otavio: the following commit in QtWebKit https://qt.gitorious.org/qt/qtwebkit/commit/34d4628b981add039a9a349723cbdff1dadca144 introduced crash issues on our embedded platforms (mainly mips platforms) Dec 30 13:41:49 otavio: but only for our Yocto builds Dec 30 13:41:55 jbrianceau: it would be CXX in this case Dec 30 13:43:46 otavio: sorry, what would be CXX ? Dec 30 13:45:25 jbrianceau: the code you pointed me checks for G++ Dec 30 13:45:42 https://qt.gitorious.org/qt/qtbase/source/68676d2128e86bbe5c650b8be7f8b78cb7f60e8f:mkspecs/features/spec_post.prf#L46 Dec 30 13:45:53 otavio: yes, g++ in the platform name, which is always "linux-oe-g++" for oe recipe Dec 30 13:46:48 otavio, but we don't take this line because QMAKE_COMPILER in not empty at this time because already defined in linux-oe-g++/qmake.conf Dec 30 13:50:01 jbrianceau: let me reread all what you said and see if I understand ... Dec 30 13:51:49 otavio: sure, no problem. Dec 30 13:55:17 jbrianceau: in theory we shouldn't use CC there it seems Dec 30 13:55:36 jbrianceau: but a OE_QMAKE_COMPILER_FAMILY or similar Dec 30 13:55:45 jbrianceau: and have it as 'gcc' Dec 30 13:56:10 otavio: yes, I first thought this (only gcc here), but I thought of a potential issue : Dec 30 13:56:48 jbrianceau: because it seems to be looping over it and matching valid ones, so first one would be ignored. Dec 30 13:57:50 otavio: as platform name is "linux-oe-g++", which does not follow Qt triplet recommendations (like linux-sh4-stmicro-ST7108-g++) Dec 30 13:58:22 otavio: the target architecture is not reflected in the name, and it's likely to be in CC Dec 30 13:58:31 otavio: like sh4-linux-uclibc-gcc Dec 30 13:59:10 otavio: so .pro files from QtWebKit looking like : Dec 30 13:59:11 *sh4* { QMAKE_CFLAGS += xxx } Dec 30 13:59:40 will match if QMAKE_COMPILER = sh4-linux-uclibc-gcc gcc Dec 30 14:00:08 when outside Yocto, QMAKE_COMPILER = gcc and platform name = linux-sh4-xxxxx-g++, so it works Dec 30 14:00:38 jbrianceau: ooooh Dec 30 14:00:44 so I think I agree Dec 30 14:01:02 but at same time, we should fix the triplet name and rework this Dec 30 14:01:27 otavio: yes, I agree having the right triplet would be cleaner Dec 30 14:02:57 otavio: with the right triplet, the following line could be removed from linux-oe-g++/qmake.conf : Dec 30 14:02:58 QMAKE_COMPILER = $(OE_QMAKE_COMPILER) Dec 30 14:03:20 because https://qt.gitorious.org/qt/qtbase/source/68676d2128e86bbe5c650b8be7f8b78cb7f60e8f:mkspecs/features/spec_post.prf will set QMAKE_COMPILER properly after Dec 30 14:03:35 jbrianceau: yes; makes sense Dec 30 14:03:57 jbrianceau: JaMa do you see any possible regression from jbrianceau patch? Dec 30 14:56:02 "which can be used to directly Dec 30 14:56:03 boot Yocto off of a USB flash drive" Dec 30 14:56:25 this meta-edison must be a practical joke Dec 30 14:58:06 :D Dec 30 15:47:55 otavio: just out of my curiosity, do you have a Continuous Integration ? if so, is there a public web access ? Dec 30 15:48:38 otavio: I'm asking because we only use qtbase & qtwebkit here, so as the change I sent for review is in qtbase, I didn't perform a full build of all Qt modules Dec 30 15:55:40 just including meta-edison will break linux-yocto for all other machines Dec 30 15:56:05 the positve things I can say about the edison BSPs are: Dec 30 15:56:14 1) downloadable without login Dec 30 15:56:20 2) use unix line endings Dec 30 15:56:28 that's it Dec 30 16:01:16 heh, another badly done linux-yocto bbappend? I thought attention had been brought to that issue in general, guess someone missed the memo Dec 30 16:01:47 like a lot of things, I'm not sure we ever actually documented it Dec 30 16:05:19 having a discussion on the mailing list is good, but if you expect new users to pick up how things should be done solely based on some previous mailing list discussion, well... Dec 30 16:06:42 FWIW, I am working with the group that produced the Edison BSP to tidy it up a bit Dec 30 16:22:27 kergoth: yes, another one that does SRCREV=foo KERNEL_VERSION=foo without any overrides Dec 30 16:22:47 bluelightning: https://github.com/koenkooi/meta-edison Dec 30 16:27:52 jbrianceau: we does; I have some customers which use meta-qt5 and those are running in our jenkins. Dec 30 16:29:07 bluelightning: are you going to fix the iot kit layer mess at same time? Dec 30 16:29:15 koen: thanks, I'll send that to some of the people in question Dec 30 16:29:54 otavio: yes, I have a bit more direct control over that one, just haven't had a huge amount of time lately Dec 30 16:30:14 sgw_: I sent three patches which updates lttng and fixes a build failure using kernel 3.18 Dec 30 16:30:19 bluelightning: ok Dec 30 16:32:27 bluelightning: I'm working against 1.7, which explains some of the issues Dec 30 16:32:55 bluelightning: I'll have actual hardware tomorrow, which means I might have actual motivation to learn how linux-yocto-custom works :) Dec 30 16:33:16 koen: is this your holiday project? Dec 30 16:33:59 koen: I have one holiday project for you, if you are lacking one... meta-java needs a lot of love Dec 30 16:34:55 bluelightning: yes, I planned to use a minnowmax, but that's seems to be made from unobtanium Dec 30 16:35:17 otavio: I only touch java if there's $$$$$ involved, which means $dayjob Dec 30 16:36:00 koen: well, I hate java a lot but several people depends on it so I've been trying to improve the layer as I can Dec 30 16:36:12 bluelightning: wireless bridge for gphoto to a dslr, all my ARM boards couldn't cope with the USB requirements Dec 30 16:36:50 otavio: I'll send patches when something breaks in the CI, can't promiss more than that, sorry Dec 30 16:37:02 otavio: ok. Should I create a pull request or the patch sent by mail is enough ? Dec 30 16:37:32 jbrianceau: patch on ml is good enough Dec 30 16:37:48 jbrianceau: we don't use pull requests for meta-qt5 Dec 30 16:38:04 otavio: great, thanks ! Dec 30 16:43:42 otavio: good catch on the gpe autologin thing, I never would have thought we still had cruft like that lying around... Dec 30 16:44:13 bluelightning: an user has reported about it existance and than I thought it'd be good to solve it Dec 30 16:45:56 Someone knows how the release notes, from yp.org website are generated? there's a tool to compare the packages? Dec 30 16:47:21 otavio: in recent times, I have gone through all the commits by hand Dec 30 16:47:39 if that sounds painful, I can tell you it is ;) Dec 30 16:48:00 I started writing a tool to help with that but it doesn't really work very well yet Dec 30 16:48:08 bluelightning: well, it'd be possible to gen a version manifest Dec 30 16:48:16 bluelightning: and use this to compare, no? Dec 30 16:49:08 well, as far as upgraded recipes are concerned you can do bitbake -s and compare that, but that doesn't list skipped recipes and it lists all variants where for a changelog you probably only need the one item Dec 30 16:50:07 also I figure to pick up all noteworthy changes you really have to go through the commits anyway Dec 30 16:50:48 http://downloads.yoctoproject.org/releases/yocto/yocto-1.6.1/RELEASENOTES Dec 30 16:50:53 Does is done byhand? Dec 30 16:51:22 actually no, that one I think Beth wrote herself, she may have a script for that Dec 30 16:52:55 I think she's out atm so I can't ask her Dec 30 16:53:39 oh ok Dec 30 16:53:47 bluelightning: can you ask her and let me know? Dec 30 16:54:06 sure Dec 30 16:54:46 the ones done by hand are these ones: https://www.yoctoproject.org/downloads/core/dizzy17 Dec 30 16:55:28 although I see the tabs are a bit messed up Dec 30 17:01:07 JaMa: another QA error fix for LICENSE field Dec 30 20:21:17 bluelightning: hmm, i seem to recall there was an issue opened regarding adding python dep bits to create-recipe, but i can't for the life of me find it. do you recall? Dec 30 20:42:13 kergoth: I'm not sure about create-recipe, but the ones I'm aware of are https://bugzilla.yoctoproject.org/show_bug.cgi?id=7036 and https://bugzilla.yoctoproject.org/show_bug.cgi?id=4451 Dec 30 20:42:33 (I hope recipetool create will replace create-recipe) Dec 30 20:42:37 ah, right, recipetool, thats the one i was thining of Dec 30 20:42:38 thanks Dec 30 20:43:18 honestly not sure how it'll map the determined deps to bitbake packages, though, unless it's kosher for recipetool create to use an existing pkgdata if available, assuming python was built :) Dec 30 20:43:20 hmm Dec 30 20:45:33 kergoth: FWIW that's what it already does for autotools dependency mapping, I think that's the only real way it can work Dec 30 20:45:40 ah, cool Dec 30 20:45:53 yeah, figured as much Dec 30 20:52:16 bluelightning: recipetool looks pretty nice, nice work on that. leaps and bounds nicer than the perl create-recipe, at least from an extensibility and maintenance standpoint :) Dec 30 20:53:28 thanks - that was what I was aiming for Dec 30 20:53:30 bluelightning: any objection to my looking into 7036, or is it on your radar for the near future? Dec 30 20:53:32 :) Dec 30 20:53:45 :) Dec 30 20:53:57 no, you're more than welcome to take it, in fact I was meaning to talk to you about it in the new year Dec 30 20:54:10 (since you already did a bunch of work in that area) Dec 30 20:54:23 I'm low on development tasks at work at the moment, so figured I'd polish off the previous python deps madness if possible Dec 30 20:54:30 sick of old half-complete things hanging over my head :) Dec 30 20:54:39 I know the feeling :) Dec 30 20:55:28 My background task to split up the external toolchain recipe sat on a topic branch for >1yr before I finished it. that was irritating :) Dec 30 20:56:06 that's one thing i wish git was a little better at, long lived branches are rather annoying to deal with Dec 30 22:10:29 gah, forgot how long my todo is for the python dep scanning bits **** ENDING LOGGING AT Wed Dec 31 02:59:58 2014