**** BEGIN LOGGING AT Mon Jul 14 02:59:59 2014 Jul 14 06:41:14 Hi All, Jul 14 06:41:47 I try to add gstreamer also include plugins to my image, however it is not included Jul 14 06:42:32 I do like this: Jul 14 06:42:38 + gstreamer1.0 \ Jul 14 06:42:38 + gstreamer1.0-plugins-base \ Jul 14 06:42:38 + gstreamer1.0-plugins-good \ Jul 14 06:42:38 + gstreamer1.0-plugins-bad \ Jul 14 06:42:38 + gstreamer1.0-plugins-ugly \ Jul 14 06:42:58 when I use gst-inspect to query which plugins is added Jul 14 06:43:09 only coreelements is added Jul 14 06:43:28 any idea why good/bad/ugly plugins not added Jul 14 07:19:20 good morning Jul 14 07:25:31 VoiceShen: did you add them using IMAGE_INSTALL_append ? Jul 14 07:26:27 Oh, no, I will try it Jul 14 07:29:44 mckoan: I put it into IMAGE_INSTALL section Jul 14 07:30:07 however, it is not included in image file Jul 14 08:08:43 VoiceShen: If I remember correctly you'll have to add the different -plugins-good-* to the image. Jul 14 08:09:19 I don't think e.g. gstreamer1.0-plugins-good pulls in the different packages that are built Jul 14 08:14:06 morning all Jul 14 08:15:50 UGT? ;) Jul 14 08:16:21 Letothe2nd: indeed, in which case good morning :) Jul 14 08:16:43 erbo: thanks, it works. Jul 14 11:37:15 Hi all. We have a bbclass (that is inherited by several recipes) that copies config files to the correct location etc. Some files are not present in all recipes so we install them conditionally. Now, what happens if I add such a conditional file to the CONFFILES variable (a file in /etc/sysctl.d for example) and a package does not have this file? Can I add files to the CONFFILES variable conditionally? Jul 14 12:05:02 and: can I add a conditional dependency in my class depending of the presence of a certain file? Jul 14 12:10:18 hsychla: does CONFFILES error out if the files don't exist? Jul 14 12:12:33 well, that was my question actually. I did not get around to testing yet Jul 14 12:13:57 test that :) Jul 14 12:14:08 FILES at least is lax about files not actually existing Jul 14 12:16:01 CONFFILES pipes through to the package manager, so I guess it depends on whether that cares or not Jul 14 12:17:39 bluelightning: so i expect rpm will moan, but not sure what opkg will do Jul 14 12:18:07 we should probably filter the conffiles list to the set of files that actually exist before passing it to the package manager Jul 14 13:01:45 is there a good way to see whats going on when one calls bitbake? Jul 14 13:02:31 depends what you mean by "what's going on" Jul 14 13:02:41 bitbake foo |cat will show you a more verbose log Jul 14 13:02:56 I want to extract the compile arguments how u-boot is built in a certain environment, but I fail to figure out where the variables are actually defined Jul 14 13:03:37 bitbake -e [recipe] will show you the variables used, and where they come from Jul 14 13:43:20 wrd: Toaster should also be able to give you a fair idea. https://www.yoctoproject.org/documentation/toaster-manual Jul 14 13:53:13 wrd: have a look at run.* (and log.*) in the temp directory for the workdir for the u-boot recipe Jul 14 13:53:53 wrd: if you're not sure where the workdir is you can find that using: bitbake -e u-boot | grep ^WORKDIR= Jul 14 14:14:05 thank you belen bluelightning. I've fixed my issues with other means. Jul 14 14:18:28 question: is my /media/realroot solution one that could be considered for backporting to Daisy? If so, I don't mind doing the integration and submitting a patch. Jul 14 14:22:18 <[Sno]> is there a bitbake cli option which shows some information about a recipe instead of building it? Jul 14 14:23:32 bitbake -e Jul 14 14:24:33 <[Sno]> so "bitbake -e perl" would show VERSION=5.14.3 for dora? Jul 14 14:24:46 will show all variable settings for when the script runs instead of running it. Great for figuring out why things aren't behaving as expected. As well as identifying the version information when the "wrong" one being run. Jul 14 14:25:03 I suggest bitbake -e perl > env.perl Jul 14 14:25:24 it generates a LOT of output. Then you can look through that file and get an idea of just what it has. Jul 14 14:25:50 <[Sno]> blloyd: I want to add a new backend for a scanner for updates and a generater for cpan modules (https://github.com/rehsack/Packager-Utils) Jul 14 14:27:58 you probably will want to use the libraries bitbake uses to do a backend, and that is more than I have done with that tool to date. Jul 14 14:28:49 <[Sno]> hmm, I should take a look, yes Jul 14 14:29:11 <[Sno]> but the -e (I have a do_rootfs running, so I cannot check) seems suitable Jul 14 14:29:28 but are you discussing a package manager to manage end packages to a distribution? What is the base format for the files it's packages? Jul 14 14:30:05 <[Sno]> blloyd: for yocto it's what bitbake does (ipk, deb, rpm, ...) Jul 14 14:30:30 <[Sno]> for pkgsrc it'll spits out Makefiles to generate *.pkg's Jul 14 14:30:57 <[Sno]> blloyd: the utility generates "*.bb" files (or should - that's the goal of Yocto/Bitbake backend) Jul 14 15:15:23 and here I thought bitbake's backends were to generate distribution packages (ipk, rpm, etc) from bitbake's compilations. Jul 14 17:08:05 RP: still checking sanity, but I think we might need to add SITEINFO_ENDIANNESS, SITEINFO_BITS, and SIZEOF_POINTER to the default BB_HASHBASE_WHITELIST. without doing so, any change to BUILD_ARCH will flow through and cause target signatures to change, meaning target sstates aren't reused when the build host changes (e.g. 32 to 64 bit). BUILD_ARCH itself isn't an issue since only its unexpanded form ends up in the signatures, but it's in the Jul 14 17:08:05 filenames, and the aforementioned 3 variables should all only ever change when BUILD_ARCH does, so it shouldn't harm anything to exclude them. thoughts? Jul 14 17:08:31 in our test case, our target kernel sstates aren't reused between 32 and 64 bit centos hosts today Jul 14 17:08:47 still making sure adding them doesn't cause reuse where reuse shouldn't occur, though Jul 14 17:09:27 obviously this wasn't an issue before the change went in to cause target signatures to be affected by changes to their native dependencies Jul 14 18:50:53 On dora I have a severe issue. Packages are being re-built. This is a serious issue in terms of GPL compliance. What if somebody has the old binary but I only have the new sources? Jul 14 18:53:18 zecke: you need sources corresponding to old binary Jul 14 18:53:24 for compliance Jul 14 18:53:47 including any patches and build rules Jul 14 18:54:31 khem: yes, but why is something like systemd being re-built? Jul 14 18:54:56 the recipe has not been changed, the content has not been changed, includes have not been changed, local.conf has not been changed Jul 14 18:55:06 its dependencies were changed, most likely Jul 14 18:55:24 i probably need to run diffsigs of all packages before the build. :} Jul 14 18:55:29 or is that being put in buildstats? Jul 14 18:55:36 bitbake-whatchanged -v Jul 14 18:55:44 or bitbake -S printdiff Jul 14 18:56:09 _before_ the build I assume? :) Jul 14 18:56:22 indeed Jul 14 18:56:47 okay and printdiff is not part of dora. :) Jul 14 18:57:14 ah, yes, that's a newer bitbake feature. bitbake-whatchanged should work if you have the STAMPS_DIR from the old build (e.g kept TMPDIR around, or saved STAMPS_DIR) Jul 14 18:58:10 zecke: but if nothing changes in systemd then rebuilding should be fine isnt it ? Jul 14 18:58:16 from complaince POV Jul 14 19:02:06 kergoth: stamps were "rebuilt". It is just the rm_work target that wants to re-run Jul 14 19:02:17 technically the binaries wouldn't be bitwise identical, but the sources would be the same, so you'd still be in compliance due to having hte sources from the previous build, afaik Jul 14 19:02:39 khem: having two .ipk files with the same name but slightly different content is a nightmare. :} Jul 14 19:03:09 the ipk files hsouldn't have the same name, at least if you're using the PR server which you should be Jul 14 19:03:19 since PR would be auto-incremented as appropriate when the checksums change Jul 14 19:03:22 kergoth: I do use the PR server. :) Jul 14 19:03:49 NOTE: Started PRServer with DBfile: /home/ortelius/poky-201310/build.sysmocom-odu/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 50415, PID: 23040 Jul 14 19:04:39 but I assume.. "there were bugs in dora and I should upgrade". :) Jul 14 19:05:09 there are always bugs in any release, the only question is weighing the migration pain vs the benefit :) Jul 14 19:05:51 the pain of building edison on modern GCC was getting high enough to migrate Jul 14 19:06:37 but these kind of rebuilds freak me out. I will disable rm_work and see what happens or maybe it is the archiver I use. :} Jul 14 19:16:49 now bluez is being re-built because I build gdb. :) Jul 14 19:18:47 What would be ideal would be to track not just inputs, but also outputs. E.g. if we rebuild a task due to vars changing, but the output of the task isn't any different, then don't ripple the change out to the tasks depending on that task Jul 14 19:18:50 but it'd be decidedly non-trivial Jul 14 19:19:28 kergoth: eg strip stuff like timestamps from binaries and md5sum them? Jul 14 19:19:57 kergoth: I would be happy if the build would break and bitbake tells me why it decided to rebuild the package Jul 14 19:20:09 possibly, yeah. but we might have to track input and output paths for all tasks. we only do that for setscene covered tasks today Jul 14 19:20:40 zecke: run whatchanged before your build, if it outputs anything, abort your automated build :) Jul 14 19:20:43 kergoth: redhat have a project to do reproducable builds, where they have flags and whatnot to ensure the same sources built twice produce bit-identical binaries Jul 14 19:20:53 rburton: huh, that sounds interesting Jul 14 19:28:14 kergoth: good old debian has a wiki https://wiki.debian.org/ReproducibleBuilds Jul 14 19:33:16 timestamps are not easy to remove, especially if its opensource there is no pattern to using time stamps some use it in version string some use in seeding random seeds for g++ Jul 14 19:33:19 and so on Jul 14 19:33:43 I tried it in vain last time even though most of software was proprietary Jul 14 19:33:50 are there any good wikis or documents for how to manage updates in the field? Both inside a single yocto release and allowing to upgrade to new images built with a newer yocto base? Jul 14 19:36:43 blloyd: sadly not as far as i'm aware, feel free to write one ;) Jul 14 19:36:46 blloyd: there is no standard update mechanism in OE/Yocto you can use Online package management like rpm/zypper dpkg/apt or opkg or use some initramfs mechanism to do image updates Jul 14 19:37:08 rpm/smartpm Jul 14 19:37:16 zypper is no longer supported Jul 14 19:38:02 blloyd: ideally you want some file system swap for atomic and safe updates, but everyone tends to write their own. i've been meaning to look at ostree for this. Jul 14 19:38:18 chromeos does this, i wonder if their tooling is open Jul 14 19:39:43 yeah i've been meaning to look at ostree for that too Jul 14 19:39:51 package-level upgrades are so risky, and full reflashing is a pain Jul 14 19:40:20 hmm Jul 14 19:41:27 maybe with systemd one can avoid this unionfs thing as well Jul 14 19:43:35 kergoth: they're still using a poky fork for the bootstrap so there's good motivation on both sides to work on it Jul 14 19:45:17 for CI/CD its a good thing I suppose Jul 14 19:49:05 OT: I have a 3.2.0er vendor crap kernel and on execve... argv[3] with "a.b.c:20000" appears to be re-written to "a.b.c\020000". it doesn't appear to be libc6. I'm not sure if the application is playing with argv/prctl either Jul 14 19:50:54 crazy app. :} Jul 14 19:51:01 * zecke kicks gpsd Jul 14 19:51:11 yikes Jul 14 19:58:19 zecke: you can also use sstate-diff-machines.sh to dump all sstate signatures at interesting points and then compare the files when something unexpectedly re-builds Jul 14 19:58:43 JaMa: thanks Jul 14 19:59:13 i need to play with that script more Jul 14 20:00:03 zecke: I would rule out kernel here Jul 14 20:01:19 zecke: is argv parsed using some str* functions Jul 14 20:02:15 kergoth: it's just other way to create stripped copy of old STAMPS_DIR Jul 14 20:02:24 * kergoth nods Jul 14 20:02:36 we have our jenkins builds capture SSTATE_DIR for later analysis Jul 14 20:02:51 and create convenience list.M which strips MACHINE names so you can compare multiple machines Jul 14 20:03:07 we're doing the same, but with this script Jul 14 20:03:27 and then we're using it also when debugging when sstate reuse is low on some developer machine Jul 14 20:03:48 you just download .tgz from last official jenkins build which populates sstate-mirror and then compare list.M files Jul 14 20:06:18 nice Jul 14 20:06:25 khem: yes, it is gps2udp that does strsep on argv Jul 14 20:07:09 not directly related, but we ship sstate to the customer, and we didn't want to distribute the intermediate artifacts, only the ones needed to build, so we're now incorporating a SSTATE_DIR trimming process to pare it down. the downside is what gets trimmed is what's needed to diagnose sstate reuse problems with bitbake -S printdiff, but it's worth it for release builds. The trim process is at https://gist.github.com/kergoth/3d73977975b17ea272ac. Jul 14 20:07:09 The key is building, wiping tmp, and building from sstate in order to get an STAMPS_DIR which only references the needed bits, not the intermediate functions like do_install Jul 14 20:07:15 * kergoth wanders off to get food Jul 14 20:08:50 some have asked if bitbake can error out if a rebuild is requested secondly if a build is requested and its not found in sstate Jul 14 20:09:03 so basically no compile should happen Jul 14 20:09:20 and bitbake should error out of sstate is not found Jul 14 20:09:32 that could be interesting. setscene-only for covered tasks Jul 14 20:10:17 my be a switch and not default Jul 14 20:10:58 opposite of —no-setscene :) Jul 14 20:11:04 (which is a really handy argument at times) Jul 14 20:11:28 FYI, after merging https://github.com/MentorEmbedded/meta-mentor/pull/262, we're now getting 100% reuse of target and 0% reuse of native/cross between 32 and 64 bit build environments, which wasn't the case previously (we weren't getting target reuse across 32/64 bit hosts. e.g. linux-yocto was rebuilt) Jul 14 20:15:47 hmmm I think they all should be just TARGET vars Jul 14 20:18:37 interesting Jul 14 20:24:15 zecke: is your option parser treating ':' special ? Jul 14 20:28:28 JaMa: starnge error yu have spotted Jul 14 20:28:31 ERROR: Recipe linux-yocto-tiny-kexecboot is trying to change PV from '3.10.43+gitAUTOINC+199943142f_aa677a2d02' to '3.14.5+gitAUTOINC+602be954ac_41d5fe27dc'. This will cause do_package_write_* failures since the incorrect data will be used and they will be unable to find the right workdir. Jul 14 20:29:12 JaMa: mixing up 3.10 and 3.14? Jul 14 20:43:42 JaMa: you still maintaing the qt5 layer? Jul 14 20:49:43 JaMa: I guess it would be more correct to say the meta-qt layer. Jul 14 20:50:31 otavio: JaMa: I am trying to run the Qt5 cinematic experience on my target, but the QPA (for xcb) isn't showing up in the rootfs. Jul 14 20:50:49 otavio: JaMa: any tips? Jul 14 21:03:50 darknighte: your question is not clear, is the xcb plugin thats failing ? Jul 14 21:04:06 to load or something Jul 14 21:04:26 khem: sorry, the plugin isn't found. Jul 14 21:04:53 I am not very familier with Qt5, but from googling around, it appears that the QPA is missing form the rootfs. Jul 14 21:05:53 khem: do you know what the name of the xcb QPA is so that I can double check? Jul 14 21:05:58 you probably are missing some dependencies for libqxcb.so Jul 14 21:06:08 see above Jul 14 21:06:11 * darknighte nods Jul 14 21:06:34 if that .so is there then do a ldd on that and see what all it needs Jul 14 21:06:42 khem: k. confirmed. that file is missing from the rootfs. Jul 14 21:06:42 and make sure those libs are there too Jul 14 21:07:09 oh then thats the first thing to do to include it in rfs Jul 14 21:07:38 * darknighte nods again Jul 14 21:08:07 khem: not sure how though. not seeing a recipe specificly for the platform plugin. Jul 14 21:08:07 see if your PACKAGECONFIG is right fot qtbase Jul 14 21:09:09 I specified xcb via my local.conf as follows: Jul 14 21:09:11 PACKAGECONFIG_append_pn-cinematicexperience = " xcb " Jul 14 21:10:09 if you had 'x11' in DISTRO_FEATURES' it should have been pulled in Jul 14 21:10:37 that construct is wrong too Jul 14 21:10:53 you need to enable it for qtbase Jul 14 21:11:14 I noticed the conditional in the recipe on X11 and have that turned on. Jul 14 21:11:19 PACKAGECONFIG_append_pn-qtbase = " xcb " Jul 14 21:11:50 check the build and see if log.do_configure has xcb enabled Jul 14 21:12:13 ahhh, I 've been looking at it for cinematic... standby Jul 14 21:12:44 qtbase is the beginnin of all qt evil that follows Jul 14 21:13:07 most od the times qtbase is configured wrongly and whole platform is compiled differently Jul 14 21:13:21 and damn qtbase takes hours to compile Jul 14 21:13:37 * khem heads to costco Jul 14 21:13:49 heh. I noticed the length of time on the compile for qt. Jul 14 21:14:19 khem: fwiw, xcb appears to be enabled correctly in qt-base Jul 14 21:26:15 khem: for reference: http://pastebin.com/79raix1W Jul 14 21:26:35 * darknighte goes to check package splits Jul 14 21:34:21 darknighte, qtbase-plugins Jul 14 21:35:16 darknighte, i think thats the package with the actual qpa plugins Jul 14 21:39:56 personally, i would like to have qtbase/qtdeclarative even more finer grained split up in packages Jul 14 21:41:03 in my quest for having the rootfs as small as possible Jul 14 21:41:27 might not be worth it though, in these days of gigabyte discs .. Jul 14 21:47:15 kroon: thx for the tip. after getting the file name I managed to figure that part out. now I have the plugins installed. Jul 15 00:02:23 so ${sysconfdir} is usually just /etc, and you prepend ${D} to get the proper path in your recipes Jul 15 00:02:55 but with -native recipes, ${sysconfdir} is actually a complete path, and ${D}${sysconfdir} is invalid Jul 15 00:02:59 what's up with that? Jul 15 00:04:04 frankly, it doesn't matter, because the files in /etc/ will be ignored in the -native version, I can just suppress them from being installed Jul 15 00:04:18 but I don't want to add extra code for it to my recipe if I don't have to Jul 15 00:05:16 it's not invalid Jul 15 00:05:47 it'll be a crazy deep path, but it doesn't matter, the code which installs it into the sysroot should be compensating Jul 15 00:05:51 (and does) Jul 15 00:06:47 I'm getting sysconfdir = "/home/maxtothemax/poky-bootchart2/build/tmp/sysroots/x86_64-linux/etc" for -native Jul 15 00:06:51 instead of just /etc Jul 15 00:07:23 so ${D}${sysconfdir} is /home/maxtothemax/poky-bootchart2/build/tmp/work/x86_64-linux/bootchart2-native/0.14.6+gitAUTOINC+f1bd345036-r0/image/home/maxtothemax/poky-bootchart2/build/tmp/sysroots/x86_64-linux/etc Jul 15 00:07:45 seems a little odd to me? Jul 15 00:10:32 that's fine, and expected Jul 15 00:10:43 prefix is set to the sysroot for native recipes to avoid issues with relocation Jul 15 00:10:45 I figured out the problem Jul 15 00:10:58 I was calling update-rc.d ${D} Jul 15 00:11:31 which I don't need to do anyway for -native Jul 15 00:11:52 you should be inheriting the bbclass, not calling it directly, which will work fine for native or non-native Jul 15 00:12:01 as its called in the postinst, which isn't run for native Jul 15 00:12:37 will look into that thanks Jul 15 00:22:58 uh meh, Yocto 1.6.1 meta-toolchain-qte is somewhat strange Jul 15 00:23:35 I built this one, then I tried to do a debug build of a simple Qt application and for some reason, even during debug build, the Qt application uses optimization flags contained in regular CFLAGS Jul 15 00:24:23 and also, during 'release' build, the result is still containing debugging symbols Jul 15 00:26:03 ah ... so the environment-setup-armv5te-linux-gnueabi script puts $CFLAGS into OE_QMAKE_CFLAGS and therefore they are included in both release and debug builds of the Qt project Jul 15 00:26:27 but as CFLAGS contains both -g and -O2 , those also leak into both release and debug build, so I always have debug symbols in the resulting binary Jul 15 00:27:04 urmmmmm Jul 15 00:30:09 aha ... looks like the meta/recipes-qt/meta/meta-toolchain-qt.inc will need to do some preprocessing by stripping the -Ox and -g flags from CFLAGS and LDFLAGS and leave that to the Qmake to configure those Jul 15 00:39:21 is that right ? Jul 15 00:44:14 https://lists.yoctoproject.org/pipermail/yocto/2013-June/014502.html someone actually complained about this before, hm Jul 15 01:10:09 Marex: from OEs POV its ok since debug info will be stripped out into packages of its own Jul 15 01:11:01 it doesnt rely on components ( qt here ) buildsystem to do that Jul 15 01:11:38 darknighte: you got through the problem or still muddling ? Jul 15 01:15:25 khem: I am just looking into it Jul 15 01:15:41 khem: the problem is noticable when you build the SDK (the meta-toolchain-qte) and use it outside of yocto Jul 15 01:16:00 khem: even in debug build, the -O2 optimization is enabled , which probably is not something you want in a debug build Jul 15 01:16:59 khem: if I were to remove SELECTED_OPTIMIZATION from the SDK OE_QMAKE_CFLAGS and OE_QMAKE_CXXFLAGS, then that'd probably solve part of the problem ... LDFLAGS would still be troublesome Jul 15 01:17:22 still ... it's not like I am confident in what I am talking about , sorry Jul 15 01:20:34 btw this changed between Denzil and Danny , in Denzil (7.0) the env setup script still worked correctly, but in Danny (8.0) I am getting this leaking of flags Jul 15 01:22:43 one should debug the final code Jul 15 01:22:51 using different O level Jul 15 01:22:58 is a wrong preset Jul 15 01:23:20 you test and debug the code that you wont ship Jul 15 01:24:29 khem: during debug, I don't want my code to be optimized so I can inspect it proper Jul 15 01:24:38 khem: during release, I want for the code to be optimized Jul 15 01:24:55 khem: btw. that's how it worked in 7.0 , in 8.0 the behavior changed so the flags are now leaking into both builds Jul 15 01:25:05 believe me you dont want that Jul 15 01:25:19 besides that Jul 15 01:25:42 ok, so I do want to debug code which is optimized ... where symbols are "(optimized out)", so it's impossible to tell etc. Jul 15 01:25:59 usually -g -O2 Jul 15 01:26:08 is most common development option Jul 15 01:27:49 ok, so when I do "qmake CONFIG += release ", I should expect the resulting build to contain debugging symbols ? Jul 15 01:28:16 it should not Jul 15 01:28:31 it does Jul 15 01:28:57 because the CFLAGS , which contain -O2 and -g do go also into QE_QMAKE_CFLAGS , which in turn get included no matter what in the build flags of this Qt project Jul 15 01:29:04 it could but image will not Jul 15 01:29:16 I am talking about using the SDK, outside of the yocto Jul 15 01:29:22 unless you include debug packages Jul 15 01:30:05 khem: I do ". /opt/poky.../environment-setup...." , then qmake CONFIG+=release , then "make" Jul 15 01:30:10 generally SDKs are used for development and then you include your app in OE/yocto proper Jul 15 01:30:51 khem: is that the reason why the behavior changed between 7.0 and 8.0 then ? Jul 15 01:31:07 are you planning to ship your app built outside yocto too ? Jul 15 01:31:19 khem: no, I'd like to understand why the behavior changed Jul 15 01:31:35 khem: I'd actually like to test both debug and release builds with the toolchain though Jul 15 01:31:41 I dont think thats the reason it might be a indesired chnage Jul 15 01:32:24 khem: I think that's pretty much it, a sideeffect of some plumbing in bitbake.conf Jul 15 01:33:15 khem: but you do agree that I should be able to do debug and release build of a Qt application, outside of yocto with just the SDK and avoid having debugging symbols in the "release" build, right ? Jul 15 01:33:26 (that's the old behavior from 7.0) Jul 15 01:33:47 its nice to have but I dont think its a must Jul 15 01:34:24 khem: my understanding is that this is exactly how it's supposed to work -- have debug symbols in the debug build only Jul 15 01:34:42 khem: esp. since the qmake adds those -g flags on it's own accord from those g++-unix.conf files Jul 15 01:36:49 I would think for a QT developer's POV its fine to have I guess Jul 15 01:38:29 khem: I think I found the culprit for this Jul 15 01:39:47 khem: if you compare denzil-7.0:meta/classes/toolchain-scripts.bbclass and danny-8.0:meta/classes/toolchain-scripts.bbclass , you will see the assignment of CFLAGS changed Jul 15 01:40:27 khem: so even the toolchains' CFLAGS were different in 7.0 and 8.0 ... Jul 15 01:40:47 sure it does change Jul 15 01:41:18 but I would suggest you to see if daisy or master has same issue too Jul 15 01:41:28 khem: I see it in 1.6 still Jul 15 01:41:46 ok Jul 15 01:42:09 file a bug that way it doesnt get lost Jul 15 01:42:26 khem: I will experiment a little more so I understand what's wrong, then I will file a bug Jul 15 01:43:01 khem: I also have a patch for the Qt here so that the CFLAGS do not contain uselessly duplicated flags Jul 15 01:43:37 (that was a simple removal of assignments from the g++-unix.conf shipped with yocto, there were remaining flags which in the meantime moved elsewhere so a duplication happened) Jul 15 01:44:25 khem: is there anyone digging in the QtE I can poke here maybe ? Jul 15 01:44:54 lot of folks do with QT5 Jul 15 01:44:59 QT4 not so many Jul 15 01:45:10 I can imagine Jul 15 01:47:28 khem: thanks, I will file those two this week Jul 15 01:47:46 np Jul 15 01:58:40 http://cacm.acm.org/ <= "killer" quake app Jul 15 02:02:09 khem: oh wait, but do I actually want the toolchain I generated to contain any predefined optimization flags in CFLAGS/CXXFLAGS/LDFLAGS ? Jul 15 02:02:27 khem: or do I want to control those myself ? Jul 15 02:11:55 Marex: usually its best to use whatever yocto selects as defaults Jul 15 02:11:57 for SDK Jul 15 02:19:44 khem: uh, so I should actually be OK with Yocto preconfiguring random optimization flags _for_ me ? Jul 15 02:19:55 that's a little strange, isn't it ? Jul 15 02:20:27 I'd expect for the projects I compile with the toolchain to configure their CFLAGS themselves instead Jul 15 02:22:36 https://lists.yoctoproject.org/pipermail/yocto/2013-January/011588.html ... and the best defaults Yocto actually selects for me do break build of various things Jul 15 02:23:04 (like U-Boot , kernel ... and this in turn makes the toolchain unusable for some usecases) Jul 15 02:23:25 the -Wl,-O1 in LDFLAGS will likely break anything which doesn't link using gcc , but with plain LD Jul 15 02:47:20 khem: gotten farther. I needed to make sure that the qtbase-plugins package was installed to the rootfs. Jul 15 02:48:10 khem: now I'm working to get the app to connect correctly to the x11 server **** ENDING LOGGING AT Tue Jul 15 02:59:59 2014