**** BEGIN LOGGING AT Fri Sep 18 02:59:58 2015 Sep 18 05:05:17 hi guys Sep 18 05:05:47 How can I get my yocto version. I have the complete yocto zip. Sep 18 05:06:05 bitbake -v tells its is 1.22.0 Sep 18 05:14:36 hello Sep 18 05:29:33 uh, zip ? Sep 18 05:30:32 did you check for example meta-yocto/conf/distro/poky.conf for DISTRO_VERSION ? Sep 18 06:47:27 hi guys Sep 18 08:24:17 I'm preparing an example, maybe bug-report, for a funky behavior. What do you propose I base it on? current tip of master, tip of some other branch, or some tag? Sep 18 08:29:53 I'll just choose current tip of fido then... Sep 18 08:31:30 good morning Sep 18 11:14:28 <[Sno]> otavio: I figured out why java crashes - https://jerboaa.fedorapeople.org/presentations/OpenJDK_Zero_FOSDEM_2015-02-01.pdf - it was the MCJIT limitation which compiles modules and not functions and can't recompile Sep 18 11:15:51 <[Sno]> so first function is compiled fine and all following "get_function_address" calls result in null pointers Sep 18 11:16:11 <[Sno]> I have to add a new module for each java function to be compiled ... Sep 18 13:54:32 \nick Sep 18 15:16:26 bluelightning: any thoughts on https://github.com/openembedded/openembedded-core/compare/openembedded:master...kergoth:scriptutils-log-improvements ? i could see 'oe.scriptutils: also send WARNING to stderr' being potentially objectionable just due to it being different than bitbake proper Sep 18 15:16:29 Is there a way to disable generation of the sstate-cache? I've got one automated builder that exists to test full rebuilds without sstate, and I'd like to avoid some of the disk space hit the sstate-cache takes. Sep 18 15:17:15 I sent a patch to core-oe but someone made me a correction, actually the correction it makes sense so I'm rewritten the patches. should I uploaded the patch again or just reply to the same subject? Sep 18 15:18:06 jmesmon: https://wiki.yoctoproject.org/wiki/Enable_sstate_cache Sep 18 15:19:04 aj_c: I don't see any note about _disable_ing in that page. Is there some keywork I'm missing? Sep 18 15:19:13 s/keywork/keyword/ Sep 18 15:20:50 aj_c: re-submit the series with 'PATCHv2' instead of 'PATCH', generally. there's a commandline argument for it. ideally also list the changes in v2 in the 0/N email. Sep 18 15:22:21 jmesmon: I've sent patch to oe-core to allow this, but it wasn't ever merged Sep 18 15:22:44 jmesmon: http://patchwork.openembedded.org/patch/17039/ Sep 18 15:23:54 kergoth: doesn't bitbake output errors on stderr these days? Sep 18 15:24:06 bluelightning: yes, but recipetool & friends don't :) Sep 18 15:24:10 hence the patches Sep 18 15:24:17 :( so far I've avoided using a patched up oe-core. Sep 18 15:24:38 JaMa, jmesmon: hmm, wonder if overriding SSTATETASKS would work Sep 18 15:24:41 kergoth: ah right, I see... sorry my brain's a bit fried today :( Sep 18 15:24:55 no worries, it's friday :) Sep 18 15:25:36 i might submit an RFC to send WARNING to stderr for bitbake, its debatable. i do think it makes sense, though, less for scripts to grep out Sep 18 15:25:57 i ran into this with newappend, as i wanted it highly scriptable, so you could grab the new append from its stdout without having to grep out the log warnings and crap Sep 18 15:26:22 in this case the logs aren't the primary output for the user, they really do belong out of band Sep 18 15:28:35 kergoth: ah, somehow just force it to be empty? what would be the best way to do that? I suppose just setting it with `SSTATETASKS=""` in local.conf won't be sufficient because bbclasses will later append to it. Sep 18 15:28:37 I *think* the series is probably worth submitting to the list, possibly without the warnings commit, though, and send that as an RFC Sep 18 15:28:53 jmesmon: indeed. could try SSTATETASKS_forcevariable = "". no idea if it'll work, but might be worth trying Sep 18 15:29:29 that is, the forcevariablew ill work, but whether emptying SSTATETASKS will have hte desired effect, that i don't know Sep 18 15:29:32 in theory it should Sep 18 15:29:56 hi, I need to make a recipe of a tool that has a custom Makefile. do you have any bbclass helper to just set the CC includes and cross stuff and call $(MAKE) clean/install and so on? Sep 18 15:30:56 * LocutusOfBorg1 usually writes a cmake script prior to write a recipe Sep 18 15:31:34 LocutusOfBorg1: that's already done where it's possible to do so. we export env vars for CFLAGS, CC, etc, and then run make -e, which lets the env vars override the makefiles. not pretty, but *usually* works. even better than that would be to read the makefiles in question and hand craft an EXTRA_OEMAKE to pass just the variables in that it obeys, rather than forcing the env vars to flow in with -e Sep 18 15:31:58 LocutusOfBorg1: make install isn't run by default, because without autotools or similar, there's no standard in regular makefiles for how to make it install into an alternate root Sep 18 15:32:02 with automake, it's DESTDIR Sep 18 15:32:09 but not all hand-crafted buildsystems use that Sep 18 15:32:18 so you'll need to write a do_install Sep 18 15:32:35 actually I just discovered that the makefile seems to be not using $(CC) Sep 18 15:32:50 you'll want to read through its makefiles regardless, to see what vars it obeys, make sure it's not doing anything crazy, make sure it has vars for the target paths that we can override (e.g. prefix/bindir/mandir/etc), and make sure it has an eequivalent to DESTDIR Sep 18 15:32:54 heh, tahts even worse :) Sep 18 15:32:54 kergoth, sure, I know that, the problem actually was the build, for the install I don't care too much :) Sep 18 15:32:57 sounds like you'll need to patch it up Sep 18 15:32:59 * kergoth nods Sep 18 15:33:02 yes, thanks Sep 18 15:33:07 sometimes we practically have to rewrite the things Sep 18 15:33:19 I was looking at the run.do_compile and I discovered it was "correct" Sep 18 15:33:22 sometimes devs don't make the best build engineers :) Sep 18 15:33:32 lots of blind copying and pasting around of things Sep 18 15:33:42 trust me as a debian developer I know this so well :) Sep 18 15:33:58 usually I write a build system and push it upstream Sep 18 15:34:02 ahh yes, desktop distros have the same issues with getting their vars obeyed Sep 18 15:34:10 particularly optimizations and whatnot Sep 18 15:34:15 but for $dailyjob doing this stuff is costly Sep 18 15:34:21 but meh, needed :) Sep 18 15:35:10 btw I did create an alias called "rebuild" that does bitbake -ccleanall $1 && bitbake $1, do you have any bitbake tool that does already this? Sep 18 15:35:32 remember that that won't necessarily rebuild from scratch, if sstate is around it'll use it Sep 18 15:35:42 trus story Sep 18 15:35:45 true :) Sep 18 15:36:12 if you just want to force it to build from scratch and don't care about possible remnants from the previous build, you can force it to build without cleaning by doing e.g. bitbake -C configure $1 Sep 18 15:36:26 but if you do worry about remnants, you can force a build from scratch by keeping your cleanall and then doing the -C Sep 18 15:36:37 the latter :) Sep 18 15:36:43 -C flags configure as 'tainted', forcing it to run the task even if it thinks it doesn't need to Sep 18 15:36:45 I use -C when I play with custom Makefiles :) Sep 18 15:36:50 ah :) Sep 18 15:36:51 yes sure Sep 18 15:36:56 yeah, there's no better way to clean and rebuild still Sep 18 15:37:06 bitbake has new syntax other than -c btw, which is pretty cool Sep 18 15:37:07 recipe:task Sep 18 15:37:12 bitbake foo:do_clean bar:do_configure Sep 18 15:37:15 usually yes, specially when I move kernel modules to builtin Sep 18 15:37:26 so i've been thining about writing a custom bitbake scheduler which forces do_clean* to run first Sep 18 15:37:27 oh... something new Sep 18 15:37:30 then you could bitbake foo:do_clean foo Sep 18 15:37:33 and it'd do what you'd expect Sep 18 15:37:35 currently it wont.. Sep 18 15:37:40 order would be undefined Sep 18 15:38:24 actually I do this when I want to clean things https://paste.debian.net/312344/ Sep 18 15:52:40 denix: what's the status of 4.1 kernel in meta-ti, is it fully supported? Sep 18 16:40:58 Has anyone else tried doing a non-gplv3 build recently? Sep 18 16:41:17 I'm wondering if the gettext failure is something specific to my environment Sep 18 16:41:23 * kergoth tries a build without any layers but oe-core Sep 18 16:42:18 RP: https://github.com/kergoth/meta-mentor/commit/0d6ebec - thoughts? Sep 18 16:53:15 kergoth: We do run a limited gplv3 build on the AB Sep 18 16:53:26 kergoth: that would seem to make sense FWIW Sep 18 16:53:57 k. i'll do some checks without local changes to check sanity, and if i keep hitting the shadow build failures without this, will see about submitting upstream Sep 18 16:53:59 thanks Sep 18 16:57:22 * kergoth ponders Sep 18 16:58:08 * kergoth checks the AB Sep 18 17:01:29 * kergoth wonders why it's succeeding there, if his logic about shadow and gettext is accurate, must be missing something, digging further Sep 18 17:03:03 kergoth: I did mean to go and look at one of my patches after your feedback btw, only to realise it slipped into master before I altered it :( Sep 18 17:03:27 kergoth: I did adjust the other one, just wanted to mention I'd not intentionally ignored the feedback, just screwed up at patch juggling :/ Sep 18 17:07:24 no worries, i just figured you might have decided against use of re for performance reasons Sep 18 17:07:46 * kergoth didn't actually test that anyway, just threw it out as a possibilit Sep 18 17:08:52 * kergoth goes to get food Sep 18 17:15:14 kergoth: yes, 4.1 should be fully working now. we are about to make a release with it, but it's fido based. so if you have any issues, especially against master, please report Sep 18 17:19:07 ah, cool, new processor sdk release coming soon? Sep 18 17:19:08 will do Sep 18 17:30:00 kergoth: well, processor sdk is a public name :) I'm making an internal sdk release, which then becomes a processor sdk... everything should be in meta-ti/meta-arago, plus the standard oe-core/meta-oe and few other layers Sep 18 17:30:16 ah, right. cool Sep 18 17:30:25 clearly unfamiliar with the process :) Sep 18 18:40:26 hey guys i am getting the following error when i try to use bitbake to make an image Sep 18 18:40:29 mv: target '3.8.7' is not a directory Sep 18 18:40:32 | creation of pre-processed config data failed Sep 18 18:40:34 | config of "standard/clanton" failed Sep 18 18:40:38 any one know a fix for this? Sep 18 18:41:35 RP, or possibly other people: Has anyone used meta-mingw with gcc 5.2 yet? I'm assuming "no" since the bbappends are still all numbered 4.9. Sep 18 18:42:09 I've worked around the obvious-ish things, and now I'm getting mysterious failures which are actually not mysterious at all, in which host cc is not defining _WIN32, leading to #error directives. And I am wondering whether I have missed an obvious step that's supposed to set that up. Sep 18 18:51:15 dasabhi: this may help: https://communities.intel.com/thread/52891 Sep 18 19:10:12 hey so i used bitbake -c devshell linux-yocto-clanton Sep 18 19:10:26 and i used make oldconfig in the new shell Sep 18 19:10:30 and then just used make Sep 18 19:10:39 it looks like it compiled succesfully Sep 18 19:10:47 but i have no idea where this kernel image is Sep 18 19:10:51 any one have any ideas? Sep 18 19:25:27 just running make probably isn't going to accomplish what you want Sep 18 19:25:47 Hmm, how did the errno import end up missing from the fetch fix, i did test builds here.. Sep 18 19:25:52 * kergoth scratches head Sep 18 20:21:37 khem`: hey can I pm you? Sep 18 20:50:29 hey i just succuessfully used bitbake to compile a kernel.... Sep 18 20:50:37 so...where in the file system is the kernel> Sep 18 20:50:38 ? Sep 18 20:50:42 kernel image** Sep 18 21:14:13 dasabhi: see the yocto project documentation. it goes the same place the images go, under tmp/deploy/images Sep 18 21:19:04 kergoth: i ran the file command on these images and one of them said Sep 18 21:19:15 kergoth: : x86 boot sector Sep 18 21:19:33 kergoth: is that the kernel image? its called bzImage-clanton...something something Sep 18 21:19:43 yes, bzImage is a kernel image Sep 18 21:20:40 kergoth: ty :) Sep 18 21:20:49 kergoth: breh Sep 18 21:28:00 seebs: I've not tried 5.2 with mingw, no Sep 18 21:35:00 So, there were a few things that were pretty easy to fix, and apparently it's generally-known that libgomp may not work in mingw32 right now, so I could turn that off. Sep 18 21:35:25 Then I ran into a bunch of warnings about how mingw headers could only be used with mingw32 targets. I note that it's just "gcc" being called to build these, and I think that's host gcc. Is that the problem, or is this something else? Sep 18 21:41:25 sometimes I wonder if we should let recipetool default to the workspace layer, and auto-create it, instead of requiring the user specify the layer all the time Sep 18 21:41:35 just to give them somewhere local to do their work, then they can move it somewhere permanent Sep 18 21:42:02 i end up creating a meta-local with yocto-layer and adding it to my build with bitbake-layers and then run recipetool against that, when doing development Sep 18 21:42:10 really common pattern for me Sep 18 22:54:44 oh, i see. it's target -> target -> native that gets halted, not target -> native -> native Sep 18 22:54:52 then why is this failing at times.. Sep 18 22:55:27 kergoth: that's what devtool add is for though Sep 18 22:56:17 I'm not creating a new recipe, though, particularly not for external sources. 90% of the time i need to modify how something is building / fix a bug in an existing recipe Sep 18 22:56:30 right, then devtool modify is your friend :) Sep 18 22:56:36 usually via metadata, not source modification Sep 18 22:56:50 so how does recipetool come into it? Sep 18 22:57:04 all the many commands for appending / altering a recipe? Sep 18 22:57:07 thats what half of its subcommands are for Sep 18 22:57:13 ok Sep 18 22:57:16 FYI I'm preparing a patchset for devtool/recipetool/ext SDK; the WIP is on paule/extsdk-devtool-fixes Sep 18 22:57:18 i'm saying i have to create a layer for it to do its work in Sep 18 22:57:26 since i don't want to shove untested stuff into my main layers yet Sep 18 22:57:51 hmm, I guess I see your point Sep 18 22:58:06 so my thought was what if recipetool defaulted to workspace the same as devtool, and had an option to specify a non-default layer to operate against Sep 18 22:58:14 not sure if that'd be good or not, just a possibility to consider Sep 18 22:58:20 might be overloading the purpose of workspace Sep 18 22:58:21 * kergoth shrugs Sep 18 22:58:54 it's all about what makes sense for the overall workflow(s) Sep 18 22:58:55 random idea from my long list of random oe/yocto ideas :P Sep 18 22:59:12 yeah, speaking of, do we have a list of use cases we're looking to cover? Sep 18 23:00:30 I'm not sure I wrote a list; Richard kind of wrote something in an RFC a while back which was the basis for my mental model of things Sep 18 23:00:47 anyway, had just noticed a common pattern in my workflows of: yocto-layer create local 1; bitbake-layers add-layer meta-local; during development, then migrate the changes, if appropriate, to their final destinations Sep 18 23:00:50 * kergoth nods Sep 18 23:00:51 k Sep 18 23:01:54 e.g. i got sick of my debugging prints in autotools_copy_aclocals changing all my signatures, when i only cared about shadow, so i used recipetool newappend to create an append for shadow and shoved autotools_copy_aclocals () override or autotools_copy_aclocals_append () there while i was debugging it Sep 18 23:02:22 (shadow is what was exhibiting my gettext failures with non-gplv3) Sep 18 23:02:28 it sounds like we need a way to turn on those debug messsages through vars Sep 18 23:02:36 but i readily admit my workflow might be different than most Sep 18 23:02:53 or maybe they should always be there and you just see them with -D or in the logs Sep 18 23:03:30 I'd be interested in an outline of what you typically do if you have time to post something to the list :) Sep 18 23:03:39 I can't imagine the need is a common one, i hate to add overhead by sprinkling debugs for unusual cases Sep 18 23:03:53 but then, i don't want to leave commented out bb.warn's around, like we have in that function right now.. Sep 18 23:03:57 heh Sep 18 23:04:03 * kergoth is a bit torn on that Sep 18 23:04:21 I've had similar issues myself... signatures changing just through adding debug messages is pretty annoying Sep 18 23:04:35 though fortunately not something I hit too often Sep 18 23:06:48 yeah, i guess keeping the debug messages in would avoid that, but i kind of shy away from too many of those after our experiences with bitbake -D becoming almost completely useless due to the excessive number of messages about non-unusual events.. Sep 18 23:07:16 right, yes... to be honest I almost never use -D due to that Sep 18 23:07:36 it's improved, but still doesn't seem to print things I typically need to see Sep 18 23:08:23 I don't think anyone who's looked at it is quite sure how to best improve it though, least of all me Sep 18 23:08:44 I'd like to focus on logging messages for unusual or unlikely events, and then only add debug informational messages to add context, with an eye toward what it'll be used for Sep 18 23:09:10 the parsing messages are clearly to answer the 'did my recipe / config file get parsed'? question, but that's better answered with other tools nowadays, particularly with variable history tracking and whatnot Sep 18 23:09:15 so those really don't serve much purpose anymore Sep 18 23:09:30 * kergoth ponders Sep 18 23:09:52 yeah, that makes sense... at least we could increase the debug level required to make those show up Sep 18 23:12:41 wtf. i just did bitbake -f shadow:do_configure Sep 18 23:12:46 and it's running shadow:do_compile after the configure Sep 18 23:12:50 that's not what i told you to do Sep 18 23:28:21 damn, Sep 19 02:09:53 aha! got it. there's a bug in autotools_copy_aclocals with the dep traversal Sep 19 02:11:57 hmm Sep 19 02:28:31 finally! https://gist.github.com/kergoth/e9b512c7b3668c098fba Sep 19 02:28:35 * kergoth sighs in relief **** ENDING LOGGING AT Sat Sep 19 02:59:59 2015