**** BEGIN LOGGING AT Thu Oct 01 02:59:59 2015
Oct 01 03:02:04 <ryansturmer> Questions:
Oct 01 03:02:23 <ryansturmer> Does the order in which I add my layer to the IMAGE_INSTALL matter?
Oct 01 03:03:20 <ryansturmer> And 2) Directory-wise, where should my layer's folder be in order to be picked up by the build
Oct 01 03:03:48 <ryansturmer> I get a
Oct 01 03:03:55 <ryansturmer> ERROR: Nothing RPROVIDES 'meta-mylayer' (but /home/ryansturmer/projects/fering/shopbot/edison/edison-src/meta-intel-edison/meta-intel-edison-distro/recipes-core/images/edison-image.bb RDEPENDS on or otherwise requires it)
Oct 01 03:05:37 <kergoth> ?
Oct 01 03:05:45 <kergoth> IMAGE_INSTALL is a variable that lists binary package names to be installed in your rootfs
Oct 01 03:06:03 <kergoth> putting a layer name there doesn't make much esnse
Oct 01 03:06:26 <kergoth> where your layer is doesn't matter as long as it's been added to BBLAYERS in conf/bblayers.conf in your build directory
Oct 01 03:08:19 <ryansturmer> ah so I'm putting things in the wrong place then
Oct 01 03:09:20 <mtetreault> @ryansturmer: Aaah that's what you meant by, you put your layer in your image!
Oct 01 03:21:40 <ryansturmer> So the configuration file that's created in conf/bblayers.conf
Oct 01 03:22:35 <ryansturmer> how is that generated?  I mean, that's created by oe-init-build-environment
Oct 01 03:22:45 <ryansturmer> but where does the list of layers that go into the build come from?
Oct 01 03:25:31 <ryansturmer> oooh ooh!
Oct 01 03:25:37 <ryansturmer> it took it!
Oct 01 03:25:55 <ryansturmer> building, seems to have absorbed the patch.
Oct 01 03:28:13 <ryansturmer> Yeah it was bailing really early on with the ncurses fail, but seems to have got clear of it.
Oct 01 03:28:20 <mtetreault> @ryansturmer: you can validate if your patch got applied by looking at the build/tmp/work directory to see the resulting source code
Oct 01 03:30:25 <ryansturmer> I will do that when (if) this build either completes or fails
Oct 01 03:30:42 <mtetreault> Ohh, I thought you were done compiling!
Oct 01 03:30:58 <ryansturmer> No, the compile failed very early previously
Oct 01 03:38:26 <kergoth> also you can use bitbake -e <reicpename> to examine the variables and make sure they're set the way you expect them to be set
Oct 01 03:40:34 <ryansturmer> Here's a question
Oct 01 03:40:47 <ryansturmer> so a layer is a collection of recipes and metadata
Oct 01 03:41:11 <ryansturmer> so the layer that defines my intel edison image defines a bunch of recipes for packages to be installed
Oct 01 03:41:22 <ryansturmer> can another layer specify that one of those recipes NOT be installed
Oct 01 03:41:46 <ryansturmer> can i override the installation directive of that layer the same way I can modify a recipe with a patch?
Oct 01 03:43:11 <kergoth> layers don't specify 'installation directives'. generally bsp layers don't do anything to your image at all. adding a layer to your config doesn't magically add its packages to your images, unless they bbappend specific images to alter their IMAGE_INSTALL
Oct 01 03:44:09 <ryansturmer> where does the IMAGE_INSTALL originate then?
Oct 01 03:44:53 <kergoth> I don't understand the question.
Oct 01 03:44:58 <kergoth> it's a variable defined in the image recipe
Oct 01 03:45:22 <ryansturmer> And the image recipe is a part of a layer, correct?
Oct 01 03:45:36 <kergoth> *you* choose whether to build the image recipe
Oct 01 03:45:39 <kergoth> in your bitbake command
Oct 01 03:45:42 <kergoth> it won't build itself
Oct 01 03:45:55 <kergoth> but yes, all recipes are part of a layer, that's what a layer is
Oct 01 03:46:24 <ryansturmer> Right, so my build configuration specifies a list of layers
Oct 01 03:46:29 <ryansturmer> and in those layers are recipes
Oct 01 03:46:52 <ryansturmer> some of those recipes are for packages that land in my distribution, ultimately
Oct 01 03:46:56 <kergoth> including a layer only makes those recipes available to you to build. nothing is forcing you to build those things, and just adding the layer to your build will not make the recipes they provide build.
Oct 01 03:47:16 <kergoth> if you don't want them built, don't build them.
Oct 01 03:47:29 <ryansturmer> But when you build, you build an image
Oct 01 03:47:37 <kergoth> and?
Oct 01 03:47:57 <ryansturmer> and that image is defined by an image recipe?
Oct 01 03:48:00 <kergoth> an image is just another recipe. if you don't like its contents, either make your own image in your own layer, or append it like you would any other recipe
Oct 01 03:48:34 <ryansturmer> So my question is, if I am customizing an image that's defined in a layer
Oct 01 03:49:06 <ryansturmer> let's say I've got a distribution like the intel edison, where an image recipe has been defined with a bunch of packages selected (in the image recipe) by appending to IMAGE_INSTALL
Oct 01 03:49:32 <kergoth> IMAGE_INSTALL is just another variable. you can add to it or remove from it in a bbappen dthe same way you would any variable
Oct 01 03:49:43 <ryansturmer> ah ok!
Oct 01 03:49:55 <ryansturmer> so another layer, defined by me, could strip things out of that IMAGE_INSTALL
Oct 01 03:49:56 <kergoth> removal can be done either with oe_filter_out (grep the layers for examples) or _remove (i.e. IMAGE_INSTALL_remove = "thing-you-want-removed")
Oct 01 03:50:05 <ryansturmer> ok cool
Oct 01 03:50:07 <kergoth> as it could with any variable in any recipe, yes, generally that's true
Oct 01 03:50:23 <ryansturmer> that's it, thanks.  Sorry round about way of getting there.
Oct 01 03:50:29 <ryansturmer> I'm still learning all the terms
Oct 01 03:50:43 <ryansturmer> the documentation is good, but there's SO much
Oct 01 03:50:44 <kergoth> np, just needed to get on the same page on what was being asked
Oct 01 03:50:48 * kergoth nods
Oct 01 03:51:01 <mtetreault> @kergoth: Do you know what's the difference between the edison branch and the normals YP branches?
Oct 01 03:54:19 <kergoth> naming confusion. the intel edison board and the yocto 1.1 edison release are entirely different things
Oct 01 03:54:26 <kergoth> the edison branch is the stable branch from that old release
Oct 01 03:54:32 <kergoth> (https://www.yoctoproject.org/blogs/davest/2011/meet-edison-yocto-project-v11-release)
Oct 01 03:54:43 <mtetreault> ooohh! I see that totally confused me out..!
Oct 01 04:00:31 <kergoth> yeah, you're not alone there, others have been confused by that. the release name existed a long time ago, the board is more recent
Oct 01 04:02:51 <mtetreault> Haha, I feel better now ;)
Oct 01 04:12:17 <mtetreault> @kergoth. I got an error building glibc when I'm using -j 8.  So I have to explicitly call bitbake glibc and then I can build my whole image. I'm somehow clueless on where to start looking for the issue. Do you have any recommandation?
Oct 01 04:12:53 <kergoth> first, make sure it still happens with master, if you're on a stable or release branch.
Oct 01 04:13:05 <kergoth> beyond that, probably a race in its buildsystem, how you fix those dependss
Oct 01 04:16:07 <mtetreault> dependss? You mean like RDEPENDS, DEPENDS ?
Oct 01 04:16:35 <kergoth> no, i'm saying it depends.
Oct 01 04:16:38 <kergoth> case by case situation
Oct 01 04:16:42 <kergoth> there's no quick answer
Oct 01 04:16:44 <mtetreault> Ohhh okay!
Oct 01 07:39:27 <mckoan> good morning
Oct 01 07:53:18 <bluelightning> morning all
Oct 01 12:14:29 <ryansturmer> ooooooh
Oct 01 12:14:43 <ryansturmer> yeah, I didn't know aboutthe branch, that's confusing
Oct 01 12:15:02 <ryansturmer> the edison board release is basically the BSP for the intel edison, packaged up with some build scripts
Oct 01 12:40:49 <clopez> after building a core-image-sato for x86 and running "runqemu qemux86" I get a Xserver with no OpenGL support at all, i have added opengl to distro-features when building
Oct 01 12:41:08 <clopez> any idea of how to enable opengl support with runqemu?
Oct 01 12:41:27 <clopez> it seems is not building the vmware kernel driver, but the uvesafb one
Oct 01 12:42:46 <clopez> (i mean vmwgfx driver)
Oct 01 12:54:01 <rburton1> qemux86 doesn't support GL
Oct 01 12:54:35 <rburton1> (presently, patches welcome)
Oct 01 12:59:21 <clopez> it supports it via gallium/llvmpipe
Oct 01 13:15:15 <ryansturmer> Further question:
Oct 01 13:15:33 <ryansturmer> I am doing a build, and one of my recipes has failed.  I have found a patch for it, and wish to apply it,
Oct 01 13:17:31 <ryansturmer> I have a custom layer, and I've successfully patched other recipes
Oct 01 13:17:45 <ryansturmer> But this one (binutils) is complaining at me
Oct 01 13:19:08 <ryansturmer> ooh maybe I've fixed it
Oct 01 13:30:47 <ryansturmer> Nope
Oct 01 13:31:05 <ryansturmer> I'm just not sure what to call my bbappend to ensure that it's applied to the recipe I want
Oct 01 13:31:24 <ryansturmer> I can do bitbake-layers show-recipes and see my recipe names
Oct 01 13:34:07 <ryansturmer> ERROR: No recipes available for:
Oct 01 13:34:07 <ryansturmer>   /home/ryansturmer/projects/edison/edison-src/meta-mylayer/recipes-devtools/binutils/binutils.bbappend
Oct 01 13:35:37 <JaMa> add _<version> or _% (wildchar)
Oct 01 13:36:04 <ryansturmer> so binutils_%.bbappend ?
Oct 01 13:36:33 <JaMa> yes if you're using recent OE and you want to apply it for all versions of binutils
Oct 01 13:36:52 <JaMa> edison maybe is too old to support % in filenames
Oct 01 13:37:02 <ryansturmer> no, seems to have an effect
Oct 01 13:37:06 <ryansturmer> although i mis-named my patch file
Oct 01 13:38:17 <ryansturmer> and I'm off to the races again!
Oct 01 13:38:40 <bluelightning> JaMa: I suspect this is for edison the board as opposed to edison the ancient branch ;)
Oct 01 13:38:51 <ryansturmer> yes
Oct 01 13:38:58 <JaMa> bluelightning: :) ah
Oct 01 13:39:02 <ryansturmer> man that's confusing
Oct 01 13:39:16 <ryansturmer> I mean, we all love naming our projects after famous scientists
Oct 01 13:39:21 <ryansturmer> hell my cat's name is edison
Oct 01 13:39:27 <ryansturmer> but we should probably diversify
Oct 01 13:39:46 <JaMa> it would be enough to say which release you're using :)
Oct 01 13:40:04 <JaMa> instead of me guessing from bbappend path :)
Oct 01 13:40:13 <bluelightning> well, in our case the branch/release was named after a character from Day of the Tentacle, and came some years before Edison the board, but yeah ;)
Oct 01 13:42:57 <ryansturmer> Day of the tentacle!
Oct 01 13:45:50 <bluelightning> https://en.wikipedia.org/wiki/Day_of_the_Tentacle
Oct 01 13:47:37 <ryansturmer> Oh i am most certainly familiar
Oct 01 13:47:41 <ryansturmer> and now I want to go play monkey island
Oct 01 13:47:47 <ryansturmer> so thanks for that.
Oct 01 13:47:53 <bluelightning> :)
Oct 01 14:01:08 <belen> "as they attempt to stop the evil Purple Tentacle—a sentient, disembodied tentacle—from taking over the world" :D
Oct 01 14:02:48 <bluelightning> belen: don't knock it, it's a classic :D
Oct 01 14:03:27 <belen> bluelightning: I wasn't. I just really like the idea of a disembodied, sentient tentacle taking over the world ...
Oct 01 14:14:14 <RP> belen: I liked the idea too :D
Oct 01 14:15:43 <][Sno][> to rebase our local patches for submitting them I rebased all my repo's to master and rebuilt
Oct 01 14:16:08 <][Sno][> with the gcc5 in master neither my kirkwood (guruplug) nor my imx6 boot's any more
Oct 01 14:16:15 <][Sno][> any hint how to dig?
Oct 01 14:16:49 <belen> RP: but I would like the tentacle to win and take over the world ;)
Oct 01 14:19:58 <RP> ][Sno][: I know there were some arm kernel gcc5 issues. You could check the linux-yocto branches and see how it was fixed there
Oct 01 14:20:26 <RP> belen: that does have a certain appeal :)
Oct 01 14:20:37 <][Sno][> RP: is something similar known to uboot?
Oct 01 14:20:53 <RP> ][Sno][: I don't know
Oct 01 14:22:53 <][Sno][> RP: git logs saying you were directly involved ^^
Oct 01 14:27:21 <RP> ][Sno][: how many patches do the git logs say I deal with a month out of interest? I don't remember any specifics of that
Oct 01 14:41:12 <JaMa> :)
Oct 01 14:44:25 <][Sno][> RP: seems to be a bit wild - cause the patches are across lot's of repos
Oct 01 14:44:41 <][Sno][> is there an easy way to choose another compiler version for the meantime?
Oct 01 14:45:02 <][Sno][> yocto ref manual didn't find for "gccversion' or 'gcc version'
Oct 01 14:46:06 <JaMa> ][Sno][: try git grep GCCVERSION
Oct 01 14:47:02 <JaMa> ][Sno][: there is still 4.8 and 4.9 version as explained in RP's commit "tcmode-default: Set gcc 5.2 as the default"
Oct 01 14:47:12 <][Sno][> cool, thanks
Oct 01 14:53:18 <Crofton|work> ][Sno][, search the kernel commit log for gcc5 and llvm commits
Oct 01 14:53:43 <Crofton|work> that's how I solved an older kernel/gcc5 compile issues
Oct 01 14:54:09 <][Sno][> Crofton|work: compiles are fine, it doesn't boot :/
Oct 01 14:54:22 <Crofton|work> annoying
Oct 01 14:55:00 <ryansturmer> gcc 5 issues are annoying!
Oct 01 14:55:21 <JaMa> all new stuff is nice but sometimes annoying
Oct 01 14:55:31 <ryansturmer> If I go edit a .bb file in my poky directory - I should just be able to re-run the build right?  I don't have to do a "clean" or anything like that?
Oct 01 14:56:04 <][Sno][> the only one I found related to my issue was 3c1245d162ccb55de1af42bcf3dbf690457bf9e4 in yocto-4.1kernel
Oct 01 14:59:07 <aj_c>  kergoth: then if add another foo.inc in another layer it will overwrite the first one?
Oct 01 15:14:10 <ryansturmer> Continuing with my build
Oct 01 15:14:16 <ryansturmer> I have a recipe that fails: subversion
Oct 01 15:14:40 <ryansturmer> so if I bitbake my-image - it takes awhile, but ultimately bombs on the subversion recipe in the do_configure step
Oct 01 15:14:45 <ryansturmer> if I bitbake subversion, though
Oct 01 15:14:49 <ryansturmer> it seems to build just fine
Oct 01 15:25:35 <ryansturmer> Should there be a difference like that?
Oct 01 15:30:13 <JaMa> ryansturmer: are you running both builds in the same directory?
Oct 01 15:30:19 <ryansturmer> yes
Oct 01 15:30:47 <ryansturmer> I'm in the directory that contains /poky and /build
Oct 01 15:30:52 <JaMa> IIRC last time I've seen similar strange issue when subversion build was failing to regexp replace something in build directory which contained "-D" string
Oct 01 15:30:55 <JaMa> or something like that
Oct 01 15:31:14 <fray> odd ball question, does anyone know if qemuarm64 SHOULD let me run arm32 (armv7) binaries?
Oct 01 15:31:22 <ryansturmer> I source poky/oe-init-build-env
Oct 01 15:31:28 <ryansturmer> and then bitbake my-image
Oct 01 15:31:30 <ryansturmer> (fail)
Oct 01 15:31:34 <ryansturmer> bitbake subversion
Oct 01 15:31:35 <fray> I'm trying to figure out if it's a qemu limitation, kernel configuration problem, or something is broken
Oct 01 15:31:36 <ryansturmer> (pass)
Oct 01 15:31:55 <JaMa> isn't it failing in subversion-native or something like that?
Oct 01 15:32:06 <rburton1> ryansturmer: pastebin with the log in would help
Oct 01 15:32:13 <JaMa> if you build your image after building subversion, then it shouldn't even try to rebuild subversion
Oct 01 15:37:13 <ryansturmer> getting logs
Oct 01 15:38:03 <ryansturmer> http://sprunge.us/GCeJ
Oct 01 15:38:15 <ryansturmer> That's the result of bitbake edison-image
Oct 01 15:39:45 <ryansturmer> oooh
Oct 01 15:39:51 <ryansturmer> there's subversion and there's subversion-native
Oct 01 15:40:24 <ryansturmer> (like you said)
Oct 01 15:42:54 <ryansturmer> Not sure I understand the difference
Oct 01 15:43:24 <ryansturmer> it looks like they're using the same source directory and .bb file
Oct 01 15:47:52 <ryansturmer> I had set CPPFLAGS but not BUILD_CPPFLAGS
Oct 01 15:48:23 <ryansturmer> so building in the native context was broken
Oct 01 15:54:10 <JaMa> 1:1, crystal ball rocks today
Oct 01 16:24:51 <aj_c> can I overwrite a foo.inc from other layer?
Oct 01 16:25:37 <kergoth> aj_c: yes, if it's in the exact same path relative to the root of the layer, and if your layer is listed in BBLAYERS before the other.
Oct 01 16:26:16 <aj_c> Thanks
Oct 01 16:46:09 <kergoth> I think there's a real need for PACKAGECONFIG_BACKFILL
Oct 01 16:46:41 <fray> kergoth, I just noticed somewhere along the line the "IMAGE_GEN_DEBUGFS = '1'" broke..
Oct 01 16:46:48 <fray> it's generating the debugfs.. but it never packages it
Oct 01 16:46:54 <fray> (creates teh tarball)
Oct 01 16:47:35 <kergoth> huh, that's not good, hadn't noticed
Oct 01 16:47:52 <fray> ya.. I have no idea how the tarball is generated any longer except something to do with image.py
Oct 01 16:49:24 <fray> I can't even find in the commit where the image part of it is.. so it's possible it got dropped in a rebase and was somehow missed
Oct 01 16:50:29 <fray> commit is: 1a6ed48c65f922c66b005aa966d7ee4878ee95e3
Oct 01 16:50:37 <fray> but that is missing the bit that tarballs it up.. :P
Oct 01 16:51:21 <kergoth> indeed
Oct 01 16:51:41 <kergoth> it's all IMAGE_NAME based, presumably you could call into oe.image with a different IMAGE_NAME and hardcoded IMAGE_FSTYPES?
Oct 01 16:51:42 <fray> hopefully I still have an old copy in my poky-contrib
Oct 01 16:51:45 <kergoth> hmm
Oct 01 16:51:59 <fray> that was my suspicion.. but the problem is I don't have a clue how that part is put together anymore
Oct 01 16:53:08 <fray> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=mhatle/debugfs&id=232acd506ec2edd5c12314ef10acb5316bd10602
Oct 01 16:53:19 <fray> that is the original patch... but I don't know if the first part even applies.. :P
Oct 01 16:55:07 <fray> ya.. I just verified that first hunk seems to be missing.. :P  I'm going to bring it back and test it.. argh.. can't believe this got missed in prior testing
Oct 01 16:56:54 <kergoth> is there an oe-selftest unit test for debugfs? if not, should probably fix that :)
Oct 01 16:57:07 <fray> I highly doubt it.. this code was written before oe-selftest.. :P
Oct 01 16:57:34 <kergoth> i really need to do better at testing all the combinations of the bits i add to the mel local.conf.sample
Oct 01 17:04:35 <fray> kergoth forward porting the old code worked.. :P  only issue is it's a bunch of small changes.. and we're not past branch point ARGH!
Oct 01 17:05:46 <fray> I think I tracked down the issue.. the version that was merged came from Khem..  and didn't have the image bits in it..
Oct 01 17:06:10 <fray> and since we (WR) carry our own version.. we ontinued to have the missing image bits and didn't notice in our regular testing it wasn't in oe-core
Oct 01 17:32:02 <kergoth> fray: this was a regression, i'd think it'd be appropriate to go in this release, though others might not agree.. also richard did just branch, so we are past the branch point, just the branch and master were probably intended to stay in sync a little longer :)
Oct 01 17:33:01 <kergoth> totally unrelated, but <3 https://sibbell.com/
Oct 01 17:33:23 <fray> I'm trying to condense down my patch.. :P
Oct 01 17:33:24 <kergoth> email notifications of new releases for any github repositories you have starred or watched
Oct 01 17:33:27 * kergoth nods
Oct 01 17:33:28 <fray> I should have somethign testable shortly
Oct 01 17:36:41 <kergoth> https://release-monitoring.org/about looks interesting, wonder how it compares to our setup
Oct 01 17:59:35 <ryansturmer> QA Issue: hostapd-daemon: The compile log indicates that host include and/or library paths were used.
Oct 01 18:01:50 <ryansturmer> What does that mean?
Oct 01 18:02:58 <JaMa> ryansturmer: look to log.do_compile
Oct 01 18:03:40 <JaMa> and search for grep -e 'CROSS COMPILE Badness:' -e 'is unsafe for cross-compilation'
Oct 01 18:03:45 <ryansturmer> ah
Oct 01 18:03:52 <ryansturmer> well dang how'd that happen :P
Oct 01 18:04:21 <ryansturmer> it's looking at my host libnl3 library
Oct 01 18:04:40 <JaMa> ryansturmer: check configure script what black magic is hard coded there
Oct 01 18:05:01 <JaMa> ryansturmer: the same check is also executed against log.do_install and config.log
Oct 01 18:05:48 <ryansturmer> found it
Oct 01 18:05:53 <ryansturmer> you guys are the best, btw
Oct 01 18:06:03 <ryansturmer> I've been nothing but noisy today and everyone has been so helpful
Oct 01 18:20:22 <ryansturmer> Some time ago, I ran across some docs that described a patch workflow for doing OE builds
Oct 01 18:20:46 <ryansturmer> where you would build, fail, then go into the source, tinker around, and then rebuild, and at the end, somehow generate a patch recipe automatically
Oct 01 18:20:52 <ryansturmer> did I dream that?
Oct 01 18:26:16 <kergoth> devtool can facilitate that
Oct 01 18:27:00 <ryansturmer> that is the keyword i needed!
Oct 01 18:27:03 <ryansturmer> thank you, found the docs
Oct 01 18:28:56 <fray> kergoth -- fix for the debugfs image gen is on the list..
Oct 01 18:29:01 <][Sno][> RP, otavio & co: meta-java and prereq patches sent via copy&paste format-patch (also for perl and meta-cpan prereqs)
Oct 01 18:29:01 <kergoth> nice
Oct 01 18:29:07 <fray> see header, comment and suggest a better way.. I don't like the duplicate code..
Oct 01 18:29:08 <][Sno][> hope that helps
Oct 01 18:29:24 <fray> but this is what I could get working quickly.. (it's cleaner then the 'backport' version I started with for sure)
Oct 01 18:29:46 <fray> also, I'd love for you (or someone else) to suggest the right setting in the oeqa to make sure this starts getting built/tested.. ;)
Oct 01 18:32:29 <JaMa> ][Sno][: in addition to comments I've already sent, meta-oe patches belong to openembedded-devel ML, read README files in toplevel directory
Oct 01 18:33:10 <][Sno][> Yet Another Mailing List to Join :(
Oct 01 18:43:58 <ryansturmer> This is a silly question probably, but should i have devtool as a part of the normal environment created by init-oe-environment script?
Oct 01 18:46:41 <][Sno][> JaMa: I don't see any comment in my inbox - do you refer a comment from past?
Oct 01 18:48:57 <kergoth> ryansturmer: yes. it's in poky/scripts or oe-core/scripts along with recipetool and others, and that should be in your PATH after sourcing the setup script. unless your'e on an old release before they were added, they should be there afaik
Oct 01 18:48:59 <kergoth> hmmm
Oct 01 18:49:02 <JaMa> ][Sno][: https://lists.yoctoproject.org/pipermail/poky/2015-October/010245.html
Oct 01 18:50:34 <][Sno][> JaMa: thanks, I sent poky patches to poky@, because I've seen a lot there ...
Oct 01 18:51:27 <][Sno][> JaMa: but I can re-gen the patches and send again to oe-devel@ tomorrow, no problem
Oct 01 18:51:30 <JaMa> a lot? https://lists.yoctoproject.org/pipermail/poky/2015-September/thread.html
Oct 01 18:51:40 <JaMa> there are only few patches for meta-yocto-bsps there
Oct 01 18:51:46 <JaMa> in whole September
Oct 01 18:51:54 <ryansturmer> I guess it makes sense that intel would use an older release
Oct 01 18:52:01 <][Sno][> I didn't clean up my inbox for a long time :(
Oct 01 18:52:02 <ryansturmer> but it looks like this scripts directory doesn't contain devtool
Oct 01 18:52:14 <][Sno][> was very busy getting openjdk working on arm5 ;)
Oct 01 18:52:36 <][Sno][> sorry for noise
Oct 01 18:57:29 <ryansturmer> looks like 1.7.2 poky
Oct 01 18:57:51 <bluelightning> ryansturmer: unfortunately that's one release behind the first where devtool was implemented
Oct 01 18:58:02 <ryansturmer> noooo
Oct 01 19:16:06 <Zyend> hello, anybody who could help me out with a compile error (while building a RaspberryPi image) ?
Oct 01 19:25:39 <ryansturmer> What's the trouble @Zyend
Oct 01 19:31:57 <Zyend> @ryan: I'm a newbie in Yocto, I tried to build a tutorial wtih raspberrypi2 and Qt5. The  build failed while compiling libssh with the following error: "error: ISO C does not support '__FUNCTION__' predefined identifier [-Wpedantic] "
Oct 01 19:32:26 <Zyend> And honnestly, i don't know how to get rid of this error within Yocto
Oct 01 19:39:52 <ryansturmer> What host are you using to do your build?
Oct 01 19:40:14 <Zyend> debian 7.9
Oct 01 19:40:32 <ryansturmer> and what yocto version/
Oct 01 19:42:08 <Zyend> fido 1.8
Oct 01 19:45:55 <ryansturmer> check the do_compile log for that package and check for more detail about what's calling the failure
Oct 01 19:47:20 <ryansturmer> Is deb 7.9 one of the "approved" build environments?  What is your gcc version (gcc --version)
Oct 01 19:48:05 <ryansturmer> I have run into a lot of errors with newer gcc versions, because of changes in how the compiler interprets warning flags (such as -Wpedantic)
Oct 01 19:48:58 <ryansturmer> When you run into these, you're pretty much looking at patching the source, or updating the build configuration to suppress warnings that are bubbling up as fatal
Oct 01 19:49:40 <ryansturmer> If you're using gcc 5 or newer, it looks like this is a known thing:  http://lists.freebsd.org/pipermail/freebsd-ports-bugs/2015-February/302737.html
Oct 01 19:54:41 <Zyend> gcc version is gcc version 4.7.2 (Debian 4.7.2-5)
Oct 01 19:54:54 <Zyend> It looks like all warnings end up with errors
Oct 01 19:58:41 <ryansturmer> One thing you can do is modify CFLAGS and CPPFLAGS in your local.conf
Oct 01 19:59:46 <ryansturmer> that will change things for all builds though
Oct 01 19:59:51 <Zyend> the local.conf in the build-xxx/conf/ ?
Oct 01 19:59:54 <ryansturmer> which is not ideal
Oct 01 20:00:20 <Zyend> how would you modify these flags in the local.conf ? I mean, the syntax ?
Oct 01 21:16:14 <sandsmark> how can I control what is installed in the sysroot where a package is built?
Oct 01 21:17:10 <kergoth> that question doesn't really make a lot of sense. what do you mean by 'where a package is built'?
Oct 01 21:19:21 <sandsmark> well, qt is built in a sysroot of sorts? and that sysroot includes gles3 headers for some weird reason
Oct 01 21:19:36 <sandsmark> which aren't included in the sysroot in the sdk, so building anything with the sdk fails
Oct 01 21:19:52 <kergoth> no, nothing is built "in a sysroot". there's a shared sysroot in the tmpdir which is used to build everything
Oct 01 21:19:53 <sandsmark> (because the qt version in the sdk expects that header)
Oct 01 21:19:56 <sandsmark> ok
Oct 01 21:20:03 <kergoth> if you need something in it, add whatever that something is to your DEPENDS
Oct 01 21:20:15 <sandsmark> well, I'd rather not have it there
Oct 01 21:20:28 <kergoth> have what where?
Oct 01 21:20:32 <sandsmark> the gles3 headers
Oct 01 21:20:36 <sandsmark> I only use gles2
Oct 01 21:20:45 <kergoth> if your build is automatically changing behavior based on the existence of a header, then your build is broken
Oct 01 21:20:51 <kergoth> and needs to be fixed to explicitly disable/enable its dependencies
Oct 01 21:20:57 <sandsmark> tell that to qt :)
Oct 01 21:21:05 <sandsmark> the qt configure script is stupid
Oct 01 21:21:20 <kergoth> the qt configure script has tons of arguments you can use to eanble/disable functionality, much like autoconf can
Oct 01 21:21:26 <kergoth> most likely you're just not passing the ones you need
Oct 01 21:21:32 <sandsmark> not really
Oct 01 21:21:48 <sandsmark> not for gles, anyways
Oct 01 21:21:57 <sandsmark> if you tell it to use gles2, it will use gles3 if it finds the header
Oct 01 21:22:13 <sandsmark> https://github.com/qtproject/qtbase/blob/dev/configure#L5339-L5352
Oct 01 21:22:52 <kergoth> then you'll need to patch it to add arguments to control that behavior, most likely
Oct 01 21:23:05 <kergoth> we don't use per-recipe sysroots, so you can never guarantee what will or won't be available
Oct 01 21:23:17 <sandsmark> indeed, but that's what I was hoping to avoid
Oct 01 21:23:17 <kergoth> that said, why is gles3 being built in your setup if you don't want it?
Oct 01 21:23:20 <kergoth> track down the dep
Oct 01 21:23:32 <sandsmark> because mesa builds it if I want gles2
Oct 01 21:23:40 <sandsmark> or, "builds" it, it's just a header
Oct 01 21:24:45 <sandsmark> ok, might be easier to just install the gles3-header...
Oct 01 21:29:15 <sandsmark> kergoth: thanks anyhow :)
Oct 01 21:29:26 <sandsmark> things make a bit more sense now
Oct 01 21:29:56 <kergoth> np. for what its worth, we intend to eventually get per-recipe sysroots to avoid this sort of hting and make the builds more deterministic (sysroot would only include bits from what you depend on), but it's not even scheduled, it's an 'eventually' item
Oct 01 21:31:20 <sandsmark> well, it would be nice, but I guess it has some overhead, and is pretty complex to get right
Oct 01 21:32:06 <kergoth> yeah. ideally it'd use symlink trees or copy-on-write or something, otherwise constructing them would slow down the builds quite a bit. could cache based on what goes into it, but still
Oct 01 21:32:19 <sandsmark> hmm, yeah
Oct 01 21:34:21 <kergoth> in the metadata, we do have access to the info about whta a task's dependencies are. autotools.bbclass copies all the .m4 files from the deps into a local dir to avoid races and whatnot. would likely use that same info in a new task that runs before do_configure to prep the recipe's sysroot, would just need to work out the details
Oct 01 22:21:02 <RP> we're certainly closer to being able to make it work that we ever have been before
Oct 01 22:38:13 <kergoth> indeed
Oct 02 00:33:23 <kergoth> damn, found a number of bugs in the shallow git support, glad that wasn't merged yet :)
**** ENDING LOGGING AT Fri Oct 02 02:59:59 2015