**** BEGIN LOGGING AT Tue Mar 22 02:59:58 2016 Mar 22 08:13:44 good morning Mar 22 08:27:21 Morning! Mar 22 08:30:01 kergoth: maybe I'm doing something overengineered here. The documentation for DL_DIR says "You can safely share this directory between multiple builds on the same development machine.". Does that mean that multiple bitbake instances are able to share the same DL_DIR at the same time without race conditions? If that's the case, a simple read-write NFS share would do the trick, if I understand correctly. Mar 22 09:04:20 mario-goulart: yes, the fetcher uses a lockfile to ensure one fetch task is fetching the same file at a time Mar 22 09:16:41 bluelightning: Thanks! So a read-write NFS share would do the trick to share DL_DIR among multiple machines, right? Mar 22 09:18:38 mario-goulart: should be OK so long as you don't get experimental with the NFS flags you enable Mar 22 09:21:02 bluelightning: excellent. Thanks a lot. Mar 22 10:16:50 is there a tool that will, for each changed SRCREV in my layer recipes, lists a summary of changes for each corresponding package? Mar 22 10:26:41 b Mar 22 12:30:05 kergoth: Do you have a moment to answer a question about binutils cross? Mar 22 12:30:12 (or cross recipes in general)? Mar 22 12:35:45 Or does anyone have experience setting up a recipe that only needs to exist on the build system as a tool for cross-compiling another recipe? Mar 22 12:43:59 Never mind... I think I got it sorted. I was getting an odd error about file format not recognized. Inheriting from cross got rid of that error. Mar 22 13:10:11 Well, except now it tosses out several warnings about "populate_sysroot not found". Is there a checklist for all the necessities of configuring a cross recipe? Trying to ferret out the hows-and-whys from one of these existing cross recipes is a bit much. Mar 22 14:07:07 Actually...it looks like setting the recipe up to split itself into native and non-native was the better route than inheriting from cross. Mar 22 15:05:46 How do you get bitbake to spit out the commands it's issuing to a given repo? Mar 22 15:06:18 For instance, it is currently picking up the wrong kernel defconfig in my set-up and I need to debug why this is happening Mar 22 15:09:37 If you go look in the build/tmp-glibc/work///<...>/temp directory, you can see the task list and log files for each. Mar 22 15:10:12 You can also use the -e to get a dump of all variables related to a recipe for sanity checking (for example, bitbake -e u-boot > u-boot.env) Mar 22 15:13:10 lag: does that help? Mar 22 15:13:21 eengie: Just trying now Mar 22 15:14:25 lag: there's also a --verbose flag I sometimes throw onto bitbake when running through specific tasks, but occasionally it's just repeating the same line of text N different ways. Sometimes it has also been helpful. Mar 22 15:15:38 eengie: I tried that, and --debug -- lots of information there, but doesn't show the commands used to build the package, nor the build output -- just bitbake's own debug/verbose churn Mar 22 15:27:22 lag: I've had an experience where some of my files weren't being picked up because they weren't in directories the packager was expecting to include. For example one installed into /usr/local//somedir but the packager was only grabbing it if it was a file or directory with files in it directly off /usr/local. The fix (for this autotools recipe) was to encourage the process using SYSROOT_PREPROCESS_FUNCS to tie in an extra Mar 22 15:30:06 eengie: Are you sure there is now way you can get OE to dump out the package's own compile log? Rather than obfuscating it and only providing the final few lines in the case of an error? Mar 22 15:32:02 lag: Definitely not sure (I'm fairly new at this myself). ;-) So in your setup have you appended the kernel recipe and have a "files" folder with your own defconfig, but it's not being used for configuring the kernel? Mar 22 15:33:53 eengie: Pass Mar 22 15:34:22 eengie: This setup should be tried and tested -- but clearly I've done something wrong, and now I need to debug what Mar 22 15:54:10 lag: belive me I feel your pain on that one. I just added a copy from ${S} to ${D} into a recipe's install method and re-ran it only to find that somehow with that change it unpacked into its recipe folder. :-| Mar 22 16:07:01 eengie: Piece of ${PROFANITY} Mar 22 16:07:42 blech, it's so annoying when recipes don't pass in explicit configure switches. Even worse when they ignore DISTRO_FEATURES. Mar 22 16:07:46 lag: ERROR: Couldn't expand ${PROFANITY} ;-) Mar 22 16:08:30 * georgem should fix gvfs but not sure he'll get around to it Mar 22 16:08:38 have you tried including an scc file (rather than your defconfig) so that the kernel recipe will then use those variables? (i.e., the scc is really just "kconf hardware defconfig") Mar 22 16:09:11 eengie: No idea what SCC is? Mar 22 16:09:49 eengie: The annoying thing is, `bitbake virtual/kernel -f -c compile` passes Mar 22 16:10:02 lag: It's just a file with extension "scc". I used it the other day to extend my kernel after seeing it in someone else's BSP layer. Mar 22 16:11:19 eengie: Do you know how to clean everything, so I'm starting again from scratch? Mar 22 16:11:55 I usually do a -c cleanall Mar 22 16:12:20 eengie: I'll try that Mar 22 16:12:40 eengie: Only issue is, I won't know if it'll work until tomorrow, as it takes FOREVER Mar 22 16:15:15 (sorry, meant for the recipe itself, so: bitbake -c cleanall virtual/kernel Mar 22 16:16:01 lag: if you want to wipe everything, all recipes, just wipe tmp and let it rebuild from sstate. shouldn't take long Mar 22 16:17:35 What I'm really trying to get the bottom of is why, do_configure and do_compile do the right thing i.e. use my own defconfig, and the do_package seems to want to collect objs from allyesconfig? Mar 22 16:18:19 kergoth: The wholes of build/tmp-glibc? Mar 22 16:18:23 whole* Mar 22 16:30:02 Right, I've moved the build/ directory and I'm starting a-fresh Mar 22 16:30:08 kbingham: What you want Bingham ;) Mar 22 16:30:26 lag: Just lurking to laugh at you :) Mar 22 16:30:49 kbingham: Touche Mar 22 16:31:02 lag: (or provide insight where available ... but ya know) Mar 22 16:31:24 kbingham: How much of an OE guru are you? Mar 22 16:32:11 lag: I did some Yocto work on previous project Mar 22 16:32:23 * kbingham ponders if the Y word is a swear word in this channel! Mar 22 16:32:40 kbingham: Same evil ;) Mar 22 19:01:36 FYI: https://www.regonline.com/Register/Checkin.aspx?EventID=1809027https://www.regonline.com/Register/Checkin.aspx?EventID=1809027 Mar 22 19:02:01 byYP dev day, they mean intro class, with some more advanced stuff :) Mar 22 19:17:47 /home/balister/sdks/release-4/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/include/boost/atomic/detail/ops_gcc_atomic.hpp:95:93: error: invalid memory model for '__atomic_load' Mar 22 19:17:47 return __atomic_load_n(&storage, atomics::detail::convert_memory_order_to_gcc(order)); Mar 22 19:18:03 I see this error compiling some source using an sdk built from fido Mar 22 19:18:11 the issue is in boost::atomic Mar 22 19:18:26 master can compile the file Mar 22 19:20:07 hmm, google suggests fix is in gcc Mar 22 21:37:12 hmm, does the OE git fetcher cope with submodules? Mar 22 21:48:28 Jin^eLD: if you use gitsm:// instead of git://, yes. i think we did it this way for compatibility, but really it should be default IMO Mar 22 21:51:41 "should be default" - what did you mean by that? Mar 22 21:52:11 basically its a git repo that uses submodules; so I am supposed to use gitsm://mainrepo.git/ ? Mar 22 21:52:35 yes Mar 22 21:52:48 ok, thanks Mar 22 21:53:04 i'm saying that instead of having to opt-in to submodule fetching by changing to gitsm, we should change the default at some future date to just always fetch submodules unless opted out with a url parameter Mar 22 21:53:28 oh, that's what you meant Mar 22 21:53:30 yes Mar 22 21:53:32 that would be nice Mar 22 21:54:47 are any other parameters needed? Mar 22 21:54:48 cp: cannot stat `/mnt/openembedded/drumgizmo/downloads/git2/git.drumgizmo.org.drumgizmo.git/modules' Mar 22 21:54:56 that's the error which I get when changing to gitsm:// Mar 22 21:58:00 ah, I should clean the recipe Mar 22 22:04:38 meta-oe has Could not inherit file classes/gobject-introspection.bbclass Mar 22 22:04:40 issues Mar 22 22:06:18 gah layer sync issue Mar 22 22:17:11 Jin^eLD: yeah might need to cleanall the recipe first, haven't tried that. might want to open a bug for that particular use case. our fetcher tests are nowhere near comprehensive Mar 22 22:17:33 Jin^eLD: the annoying part with the tests is there's so much state that lies in DL_DIR, so you need to reproduce that state to cover all the use cases.. Mar 22 22:21:56 I see... well cleaning did help, thats what the manual suggested, but do not know yet if it works, have to tune the configure script of the package first Mar 22 22:22:00 trying to package drumgizmo Mar 22 22:39:45 suhr: how's it going with disabling sse? :> Mar 22 22:39:48 oops wrong window Mar 22 22:45:06 Jin^eLD: you really need to label your windows ;) Mar 22 22:49:10 bluelightning: I have none :) I run IRC in split mode in a terminal, I use the ancient BitchX client :) Mar 22 22:50:51 wow, old school. i haven't run that in years, since switching to irssi long ago Mar 22 22:51:05 so basically I have to press some key combo to switch active channel :) Mar 22 22:53:31 kergoth: yeah, I got used to it and could never switch Mar 22 23:44:24 nite **** ENDING LOGGING AT Wed Mar 23 02:59:58 2016