**** BEGIN LOGGING AT Tue Dec 13 03:00:01 2016
Dec 13 03:14:24 <kergoth> it's a binary file, a dump from python's pickle module
Dec 13 03:16:08 <bluelightning> he/she is gone already
Dec 13 06:34:59 <LetoThe2nd> abelloni: concerning the topic lately, it seems zephyr can now be build with OE :) https://lists.yoctoproject.org/pipermail/yocto/2016-December/033521.html
Dec 13 08:15:23 <aV_V> how do u cross-compile a simple C program? I've run the setup-environment script but when I try to compile it doesn't find the headers
Dec 13 08:23:45 <aV_V> oh I found it, y should use $CC instead of compiler binary
Dec 13 10:54:23 <eduardas_m> hello, I am having trouble adding sqlite3 Qt5 plugin to my qtbase-plugins package (I at least expect it to go there)
Dec 13 10:54:30 <eduardas_m> I do PACKAGECONFIG_DISTRO_append_pn-qtbase = " sql-sqlite"
Dec 13 10:54:40 <eduardas_m> in my local.conf
Dec 13 10:55:15 <eduardas_m> then rebuild qtbase, but can not find sqlite3 plugin in the generated packages
Dec 13 10:55:24 <eduardas_m> what am I doing wrong?
Dec 13 11:07:41 <ernstp> eduardas_m: is it split up in a separate package that you also have to install?
Dec 13 11:07:56 <ernstp> by depending on it from your image...
Dec 13 11:19:43 <eduardas_m> ernstp, not as far as I am aware of
Dec 13 11:19:49 <eduardas_m> will check
Dec 13 12:17:03 <Ox4> hello guys
Dec 13 12:17:53 <Ox4> I cannot find yocto variable which specifies the location of the built image. Is there such variable?
Dec 13 12:18:23 <rburton> Ox4: DEPLOY_DIR?
Dec 13 12:18:40 <rburton> almost all variables are defined in bitbake.conf, so always worth grepping that first
Dec 13 12:19:14 <Ox4> rburton: thank you!
Dec 13 13:06:43 <Strike5150> Morning, I'm still working on my issues with CF Card and a genericx86 Image.  I'm compiling one against meta-intel(intel-core2-32) now but still have some things that don't make sense.
Dec 13 13:06:54 <Strike5150> The image when it boots says waiting on removable media
Dec 13 13:07:09 <Strike5150> basically it thinks the rootfs is on a USB, but its really on the CFDisk which it just booted from
Dec 13 13:07:19 <Strike5150> Where can I find the yocto variables to control that behavior
Dec 13 13:07:38 <Strike5150> is the hddimg the correct image to bake onto the CFDisk, remember the CFDisk is basically its hard drive.
Dec 13 13:07:43 <Strike5150> not removable media
Dec 13 17:24:51 <kergoth> oof. digging into the boost buildsystem hurts my head
Dec 13 17:25:28 <rburton> kergoth: SUCKER
Dec 13 17:27:29 <kergoth> indeed.
Dec 13 17:27:47 <kergoth> seems it appends its own -march/-m32/-m64/etc still
Dec 13 17:28:00 <rburton> yes it does
Dec 13 17:28:01 <kergoth> guessing we just got lucky and it was compatible in most cases
Dec 13 17:28:06 <kergoth> easy to disable, but still
Dec 13 17:28:17 <rburton> there's a number of places where it decides to add march flags
Dec 13 17:29:07 <kergoth> would be nice if it was easier to override without a local patch, but this'll do..
Dec 13 17:29:43 <khem> has anyone tried qmake on target ?
Dec 13 17:30:10 <khem> I get basic failure like Project ERROR: Unknown module(s) in QT: core
Dec 13 17:30:35 <khem> I guess I am missing some packages but wanted to see if someone has already blazed the trail
Dec 13 17:32:01 <kergoth> grr
Dec 13 17:33:37 <khem> cross works ok
Dec 13 17:42:55 * kergoth kicks boost repeatedly
Dec 13 17:43:08 <Crofton> lol
Dec 13 17:43:13 <Crofton> boost
Dec 13 17:44:08 <rburton> kergoth: heres an idea
Dec 13 17:44:13 <rburton> kergoth: port boost to meson
Dec 13 17:44:19 <rburton> its probably a more productive use of time
Dec 13 17:44:27 <kergoth> ha
Dec 13 17:44:54 <rburton> good news: we have meson classes on the list, and the libepoxy update can be switched from autotools to meson
Dec 13 17:44:59 <rburton> something to try post M1
Dec 13 17:45:11 <kergoth> working through an oe-core world build for x32, grabbing patches from various other distros as needed
Dec 13 17:45:41 <khem> gst uses meson
Dec 13 17:45:46 <khem> too hmm
Dec 13 17:51:35 <kergoth> huzzah, boost built
Dec 13 17:51:40 * kergoth does a little dance
Dec 13 18:11:10 <Strike5150> o/, If I have one operating system and multiple hardware platforms which require different config files depending on the hardware.  What is the best way to organize that in Yocto.
Dec 13 18:11:44 <Strike5150> The config files are for programs compiled against that architecture/machine
Dec 13 18:12:21 <Strike5150> And otherwise have little do with it, but I can tell based on the machine it was compiled for which config file to use
Dec 13 18:25:21 <jstashluk> abelloni: khem: Thanks for telling me about wic. My build machine is now making a bootable am335x devkit image from my vendor BSP without a mounted SD card or root permssions.
Dec 13 18:38:59 <kergoth> Strike5150: that's what the MACHINE is for
Dec 13 18:41:54 <kergoth> bluelightning: thoughts on setting the default recipe argument for devtool update-recipe based on $PWD, if it's relative to the source tree of a recipe in the workspace?
Dec 13 18:42:19 * kergoth adds todo to look at tinfoil2
Dec 13 19:04:44 <dl9pf> hi!  devtool experts:    working with YP 2.2/morty, I try to
Dec 13 19:04:44 <dl9pf> "devtool add https://ftp.gnu.org/gnu/hello/hello-2.10.tar.gz"
Dec 13 19:04:44 <dl9pf> "devtool build"
Dec 13 19:04:44 <dl9pf> As its a perfect autotooled project, it should just build (TM) , but it fails
Dec 13 19:06:31 <bluelightning> kergoth: hmm, that sounds like a great idea actually
Dec 13 19:06:42 <bluelightning> kergoth: yes please do, it needs review
Dec 13 19:07:03 <bluelightning> dl9pf: it should yes, let me take a look
Dec 13 19:07:45 <dl9pf> that is both with an esdk but also in a project env (qemux86)
Dec 13 19:13:36 <bluelightning> dl9pf: so the reason is hello is actually "broken" and doesn't build with S != B
Dec 13 19:13:39 <bluelightning> which is pretty shameful
Dec 13 19:13:53 <bluelightning> anyway, you just need to specify -s on the devtool add command line
Dec 13 19:14:17 <bluelightning> it would be nice to be able to figure that out for the user but I can't see a practical way
Dec 13 19:15:24 <bluelightning> (the thought occurs, in a training situation that might be an opportunity to discuss the issues around S != B depending on the level of the class)
Dec 13 19:32:43 <kergoth> meh, 32 bit userland with 64 bit bootloader/kernel setups are a bit irritating, except in cases where the underlying buildsystem doesn't obey our tuning at all. someday would be nice to be able to set DEFAULTTUNE on a per-recipe basis for special cases
Dec 13 19:34:47 <dl9pf> bluelightning: sigh, yes. brokensep ...
Dec 13 19:56:09 <kergoth> hrmph, ICE compiling qemu for x32
Dec 13 20:18:38 * kergoth hacks on x264
Dec 13 20:24:00 <kergoth> x264 does not seem well maintained
Dec 13 20:32:57 <sandsmark> x265 is the new hot thing
Dec 13 20:34:41 <sandsmark> https://github.com/mirror/x264/graphs/contributors the commit graph looks pretty stable though
Dec 13 20:49:27 <dl9pf> bluelightning:  is "devtool add -s"  same as autotools-brokensep ?
Dec 13 20:49:41 <bluelightning> dl9pf: it is yes
Dec 13 20:49:53 <dl9pf> hmm ...
Dec 13 20:50:15 <bluelightning>  -s will trigger the use of autotools-brokensep if it would have otherwise inherited autotools
Dec 13 20:50:38 <dl9pf> fails in this sequence:
Dec 13 20:50:38 <dl9pf> devtool add _url_to_hello_
Dec 13 20:50:38 <dl9pf> devtool edit-recipe hello # add -brokensep before we build
Dec 13 20:50:38 <dl9pf> devtoo build # fails
Dec 13 20:53:11 <dl9pf> ahh ...   without -s we do not set EXTERNALSRC_BUILD to the EXTERNALSRC ...
Dec 13 20:53:24 <dl9pf> that is why it fails above even if we add autotools-brokensep
Dec 13 20:53:28 <dl9pf> eek
Dec 13 20:54:08 <dl9pf> so does autotools-brokensep not set EXTERNALSRC_BUILD then ?
Dec 13 20:56:46 <dl9pf> bluelightning:
Dec 13 20:56:48 <dl9pf>         if externalsrcbuild:
Dec 13 20:56:48 <dl9pf>             d.setVar('B', externalsrcbuild)
Dec 13 20:56:48 <dl9pf>         else:
Dec 13 20:56:48 <dl9pf>             d.setVar('B', '${WORKDIR}/${BPN}-${PV}/')
Dec 13 20:57:19 <dl9pf> so by adding -brokensep in the recipe, we don't influence externalsrc.bbclass ...
Dec 13 20:57:44 <dl9pf> only EXTERNALSRC_BUILD does this which is setup only by devtool -s  not  autotools-brokensep
Dec 13 21:00:23 <bluelightning> dl9pf: that's correct, so I may have misled you a bit
Dec 13 21:01:39 <dl9pf> devtool -s sets EXTERNALSRC_BUILD, but not autotools-brokensep  (it enforces the same outcome, but with different methods)
Dec 13 22:26:20 <bluelightning> dl9pf: hmm, that is probably a bug, we do want the recipe to work after taking it out of the devtool environment and for that that would be required
Dec 13 22:27:00 <dl9pf> yep ... basically  "-s" would need externalsrc + -brokensep to cooperate
Dec 13 22:27:47 <dl9pf> i wonder what is better, externalsrc to honor the -brokensep, or externalsrc not setting externalsrc_build in favour of -brokensep
Dec 13 22:29:31 <bluelightning> I don't think we'd want to have them interact, just that we need to do both
Dec 13 22:30:15 <dl9pf> well, if you do "devtool add -s" , you can quite certainly  s/autotools/autotools-brokensep/ in the recipe template
Dec 13 22:31:03 <bluelightning> right, that would make it easier for users, I'm just not sure that you can switch that without cleaning
Dec 13 22:31:22 <bluelightning> (assuming externalsrc were made to cooperate with it)
Dec 13 22:32:14 <dl9pf> iirc thats a problem ... how to properly clean-up when you screwed things on a recipe with devtool
Dec 13 22:32:14 <dl9pf> e.g. reset will not delete sources/hello  so if you re-run add it will complain
Dec 13 22:33:19 <bluelightning> yes... there was an incidental discussion about that on the list yesterday as it happens
Dec 13 22:34:22 <bluelightning> basically that's intentional as I'd rather avoid enabling people to delete source trees that have valuable changes in them
Dec 13 22:34:30 <kergoth> i wouldn't want devtool removing my modified source tree, better to let it stay behind  and let me remove it
Dec 13 22:34:32 <kergoth> indeed
Dec 13 22:35:09 <kergoth> there's no clean way for it to know when the repo has value or not. i could have stashes, etc
Dec 13 22:35:14 <dl9pf> ok, but that breaks your "devtool" workflow and is not clearly documented when you do "reset"
Dec 13 22:35:30 <dl9pf> aka "I did leave sources here, go check and remove yourself."
Dec 13 22:35:44 <bluelightning> dl9pf: er, reset does tell you exactly that
Dec 13 22:36:23 <kergoth> yes, reset explicitly tells you the source tree is left behind.
Dec 13 22:36:41 <bluelightning> NOTE: Leaving source tree /home/paul/poky/poky/build/workspace/sources/hello as-is; if you no longer need it then please delete it manually
Dec 13 22:37:26 <dl9pf> True, I stand corrected. Just tried it.
Dec 13 22:37:29 <bluelightning> we could say why we're leaving it or what the user should check, perhaps
Dec 13 22:38:01 <dl9pf> well, I ended up calling add again and it yelled at me as the folder was present ...
Dec 13 22:38:14 <bluelightning> yes, that is an unfortunate side-effect
Dec 13 22:38:15 <kergoth> devtool modfiy has an argument to use the existing tree rather than extracting it
Dec 13 22:38:20 <kergoth> don't use add much, myself
Dec 13 22:38:22 <bluelightning> in any case, perhaps we ought to think about some way to let people re-enter the add process with different arguments for this kind of scenario
Dec 13 22:38:51 <dl9pf> or move into "archive" folder with  name.$(date)
Dec 13 22:39:16 <dl9pf> this way you can call add / reset as often as you want and the changes are still preserved
Dec 13 22:40:02 <bluelightning> hmm, assuming devtool was the one that created that directory, yes - we'd probably need to have an option to disable the renaming for people that want to leave it at the same path, but it would be a reasonable default behaviour
Dec 13 22:40:19 <kergoth> i'd rather see it recognize that the source tree already exists and disable extraction for that case, if it could check if it's current, or something
Dec 13 22:40:20 * kergoth shrugs
Dec 13 22:42:04 <dl9pf> well,  cornercases, true. but I'm just replicating user joe developer  here ...  starting with devtool
Dec 13 22:42:56 <kergoth> don't you think joe developer would be surprised if resetting and re-adding results in losing the changes they made to the source tree due to moving that source tree? more than that, their terminals which are already within the source tree will now be within the archived tree, and if they make more changes there, they won't have any effect
Dec 13 22:43:03 <kergoth> possibly best to document the use cases..
Dec 13 22:44:14 <paulg> yeah, 'cause people always read the docs.
Dec 13 22:44:14 <dl9pf> kergoth: your's is valid as well ...    just the add+reset+(re)add   is not unlikely
Dec 13 22:44:16 * paulg runs
Dec 13 22:44:25 <dl9pf> lol, paulg
Dec 13 22:46:16 <kergoth> quoting from PEP20, the zen of python: explicit is better than implicit. by that, the current behavior is best. it leaves what to be done with the source tree in the user's hands
Dec 13 22:46:18 * kergoth shrugs
Dec 13 22:48:23 <paulg> sounds awfully like the old unix adage of "give them enough rope..."
Dec 13 22:49:05 <paulg> <--- not a python fan.
Dec 13 22:49:32 <kergoth> it's more a situation where the default behavior just can't be perfect for every use case, they're mutually exclusive
Dec 13 22:49:35 <kergoth> IMO anyway
Dec 13 22:49:48 <kergoth> (we have a lot of that, hence oe/yocto's flexibility)
Dec 13 22:50:50 <paulg> yeah, the wider the audience, the more that becomes an issue.
Dec 13 22:51:18 <moto-timo> and with the flexibility comes the complexity...
Dec 13 23:46:37 <bluelightning> moto-timo: indeed, it ought to be our motto that one...
Dec 13 23:48:20 <Crofton> We should rewrite bitbake in perl
Dec 13 23:52:40 <moto-timo> perl6
**** ENDING LOGGING AT Wed Dec 14 02:59:59 2016