**** BEGIN LOGGING AT Wed Jul 29 02:59:58 2015 Jul 29 04:25:28 hello... Jul 29 04:40:41 maybe init-install.sh in initrdscripts is for installing on a drive? Jul 29 04:41:34 i am trying to figure how to partition/install on 250 Gb SSD Jul 29 06:51:52 what is yocto project reference 1.7.2 kernel? Jul 29 07:23:38 good morning Jul 29 08:11:30 morning all Jul 29 08:14:22 morning Jul 29 08:42:49 morninng Jul 29 08:44:18 Hi all, I have two packages providing the same virtual/package. Is there a way to make bitbake prefer one of the packages by default, if no PREFERRED_PROVIDER_virtual/package is set by the user? I am looking for functionality like DEFAULT_PREFERENCE = "-1" provides for different package versions. Thanks! Jul 29 08:50:16 Rootert: there are priorities for layers Jul 29 09:13:36 miandonmenmian: Yes I am aware of that. Unfortunately, both packages are defined in the same layer. I have found some anonymous python script to effectively skip one package provider if the preferred provider is not set explicitly, but that feels a bit clumsy. Jul 29 09:18:10 Rootert: I think DEFAULT_PREFERENCE should work in this case then Jul 29 09:20:28 bluelightning: That was my first guess too, but it didn't seem to work when I tried it. I will give it some more testing then. Thanks. Jul 29 09:32:41 Hi, i'm having problems to build my kernel with yocto (i'm using meta-xilinx for ZC-702) and i need a 3.8 kernel, i have all the patches, the config and the git. But creating the same directory structure (starting from recipes-kernel) and setting prefered version doesn't work, is the kernel version setted somewhere else ? or am i using the wrong solution to get my kernel build instead of the default for the zc-702 ? Jul 29 09:34:11 Happycat: there are some points to it. the kernel recipe has to mark itself as compatible for the machine, for example Jul 29 09:35:00 Hi! I'd like to know if one can specify LINUX_KERNEL_TYPE inside an image recipe? Jul 29 09:35:07 oh yes you are right, i saw that and forgot it. thanks ! , but the why does the prefered version doesn't throw an error ? Jul 29 09:36:17 Happycat: AFAIK preferred != required. Jul 29 09:36:22 Happycat: PREFERRED_VERSION or PREFERRED_PROVIDER on something that isn't available will throw a warning Jul 29 09:36:27 not even from a linguistic point of view. Jul 29 09:36:40 Guest25051: nope. it's variable used in the kernel recipe. Jul 29 09:36:51 Happycat: you may also find your PREFERRED_VERSION or PREFERRED_PROVIDER are being overridden - bitbake -e | less will tell you for sure Jul 29 09:38:23 Ok i'll see all of that , i just added the COMPATIBLE_MACHINE. thanks for the help once again :) Jul 29 09:38:44 ndec: OK. So is there a way to specify that an image recipe depends on a tiny kernel other than depending on linux-yocto-tiny (I'd like to still depend on virtual/kernel)? Jul 29 09:39:20 nope. it's a distro setting. Jul 29 09:39:22 miandonmenmian, bluelightning: Found a solution :) Apparently, DEFAULT_PREFERENCE is not taken into account when weighing providers. A package provider named exactly the same as the virtual package will be preferred though, and it gives me the opportunity to explicitly set a different provider if I want to. Thank you both for your help. Jul 29 09:40:06 Guest25051: an image recipe just aggreates packages already built. Distro settings can impact how these packages get built in the first place. Jul 29 09:42:12 miandonmenmian__: Sorry, i only just noticed the underscore suffix in your nick. See above. Jul 29 09:42:30 ndec: OK. So there is no way to build a normal image with a standard kernel and a recovery image with a tiny kernel using the same local.conf? Jul 29 09:47:12 Guest25051: well, that's an interesting use case.. i would say no at first sight. but i could be wrong.. Jul 29 09:48:55 the tiny kernel for the recovery image would have to be substantially modified so it did not stage the files a normal kernel recipe does Jul 29 09:49:06 it should be possible, but it's not a use case we support out of the box Jul 29 09:50:20 bluelightning: for the moment, the tiny kernel would be the same as the other but configured differently using the tiny kernel type Jul 29 09:51:18 It's unfortunate this use case is not supported but I'll do it differently if I have to ;-) Jul 29 09:51:40 Guest25051: without those modifications, you'll get errors because the system expects there to be only one kernel staging the kernel source, headers and artifacts Jul 29 09:51:56 (which are used for other recipes that need those things) Jul 29 09:52:53 ndec: bluelightning: thanks for your answers! If someone has a solution, feel free to tell me ;-) Jul 29 09:53:49 the answer is that you need 2 machines, and built separately. which should be fine, anyways, since all binaries would be reused from the sstate Jul 29 10:26:35 Rootert: great, thanks for noticing and sharing. I had several layers, and had a similar issue. but i just disabled one of them :P Jul 29 10:43:35 hi guys Jul 29 10:46:42 I have a variable in the local.conf which I then use in recipes to trigger updates to do_install Jul 29 10:47:08 initially the variable is set to 'x' and things work fine Jul 29 10:47:26 i change the variable to 'y' and it works fine again Jul 29 10:47:54 but then if I change the variable back to 'x' the intended behavior does not occur Jul 29 10:48:44 can anyone help on that? Jul 29 10:54:02 bluelightning: ping... can you please comment? Jul 29 10:55:04 abelal: I would assume what's happening is that the output produced when the value was 'x' is being restored from the sstate cache the second time Jul 29 10:55:47 abelal: in most cases that's the correct behaviour; if it's not then the inputs to the task aren't adequately defined Jul 29 10:56:43 bluelightning: I am checking the variable in do_install_prepend() to make things change Jul 29 10:57:03 bluelightning: shouldn't that be enough to trigger a re-run of do_install? Jul 29 10:59:09 abelal: with no other information, since you've already run it with that value, you just get the result of the tasks that follow it (e.g. do_package_write_*) - because it has seen the signature for do_install and therefore all tasks that depend on it before, it assumes it can use the previous output for those tasks Jul 29 11:02:38 bluelightning: thanks a lot :) Jul 29 12:26:40 guys, I have a problem with kernel modules, as usual :) Jul 29 12:27:14 when I just flashed an image, the kernel modules are inserted automatically after booting Jul 29 12:27:28 but if I reboot the board, they aren't Jul 29 12:27:37 when two layers have different recipes for the same package... which one gets used? the first one to be listed in local.conf or the last one? in other words... which layer gets more priority in local.conf.. the ones at the top or the bottom ? Jul 29 12:28:47 clopez: in the top Jul 29 12:47:02 what bitbake command lists the DESCRIPTION field of a package? Jul 29 12:49:01 alternatively, what bitbake command shows the recipe path that describes a given package? Jul 29 12:50:43 libv: there isn't such a command, notout of the box at least Jul 29 12:51:18 libv: bitbake-layers show-recipes mostly gives you the latter though Jul 29 12:52:04 bluelightning: hrm, wouldn't such a command make the whole thing a lot more intuitive? Jul 29 12:52:05 ok, thanks Ox4 :) Jul 29 12:53:05 libv: maybe, but in terms of "find me a recipe for xyz" we do have the layer index - http://layers.openembedded.org/layerindex/branch/master/recipes/ Jul 29 12:53:16 that covers all layers, not just the ones in your configuration Jul 29 12:53:36 all public layers whose maintainers have added them to the index, that is Jul 29 12:53:57 bitbake -i Jul 29 12:54:42 it's worth noting, there is a distinction between recipes and packages Jul 29 12:54:59 pidge, hello Jul 29 12:55:36 bluelightning: i wish i was that lucky to actually get to use yocto directly :) Jul 29 12:55:53 that would severely solve a lot of problems with this broken project i am in :) Jul 29 12:56:58 AzaToth, hi Jul 29 12:57:04 libv: well, if there's missing functionality that prevents you from moving then do let us know - I know it's often not that simple though Jul 29 12:57:16 bluelightning: yeah, but bitbake -s gets package names, description fields are afaict also tied to packages, it would be quite intuitive to get both the description and the path and name of the recipe with another command :) Jul 29 12:58:20 pidge, did you get time to look into the issue? Jul 29 12:58:45 bluelightning: it's old style embedded mindset and processes that prevent progress here :) Jul 29 13:01:57 AzaToth, no, I didn't. I will try to look at it this week. I've been working on some other things. Jul 29 13:12:18 Hi All Jul 29 13:12:32 I am trying to remove some rpms from being installed in the rootfs. IMAGE_INSTALL_remove = " foo bar " in local.conf or in image.bb do no seem to have an effect. Jul 29 13:12:39 Is it because the foo and bar rpms do not exist in the IMAGE_INSTALL as strings, but get pulled as dependencies ? Jul 29 13:13:20 probably; you can use -g (iirc) to generate a dependency graph Jul 29 13:13:24 I need the foo and bar packages to be compiled for another package. Jul 29 13:13:32 darkspike: almost certainly Jul 29 13:13:57 can i do something about it ? to actually remove them Jul 29 13:14:15 buildhistory's dependency graphs are the way to track down the dependency chain that pulls in the packages: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#maintaining-build-output-quality Jul 29 13:14:52 you can use PACKAGE_EXCLUDE, but all that's likely to do is give you an error telling you the first-level dependency preventing the package from being removed Jul 29 13:15:38 bluelightning: i did check the dependency graphs, an i found that foo and bar are just a build dependency. They are not needed at runtime. Jul 29 13:16:12 darkspike: buildhistory or bitbake -g ? Jul 29 13:16:39 bluelightning: bitbake -g -u depexp Jul 29 13:16:55 darkspike: right, that's probably not going to be sufficient Jul 29 13:17:08 buildhistory's graphs show the runtime dependencies as the package manager saw it when constructing the image Jul 29 13:18:29 bluelightning: where do i get theese "buildhistory's graphs" ?, is it from reading the log files in the temp folder ? Jul 29 13:19:51 darkspike: see the link I pasted just a few lines above, it describes how to enable buildhistory and what it gives you Jul 29 13:22:11 bluelightning, rink_ thanks for your help guys !! Jul 29 15:18:52 morning Jul 29 15:27:38 howdy folks. Can anyone tell me a command to display MACHINE_FEATURES? Jul 29 15:28:35 I am trying to set HAVE_TOUCHSCREEN=1, but it does not seem to "take", and I can't figure out how to debug it Jul 29 15:31:59 bitbake -e is your friend :) Jul 29 15:32:57 I wonder if it'd be useful to try a custom bitbake scheduler which just prioritizes do_clean* before all other tasks, so you could run bitbake foo:do_clean foo to clean & rebuild it in one pass Jul 29 15:33:08 * kergoth ponders Jul 29 15:39:04 thanks, I did run on the recipe: bitbake -e core-image-sato > sato.txt. Searching the file, I see the following: # $MACHINE_FEATURES [4 operations] Jul 29 15:39:48 I looked up line 276 of the referenced documentation, but it does not provide a list of features. Is this a command that can be run? Jul 29 15:48:15 there's no official set list of available machine or distro features. there are parts of the metadata that check to see if features are set, that's it Jul 29 15:48:28 the yocto docs might list some of it, though it could potentially be out of date Jul 29 15:48:29 not certain Jul 29 15:53:53 thanks. MACHINE_FEATURES go in the machine.conf (beaglebone.conf above), and DISTRO_FEATURES go where? Jul 29 15:54:14 into the distribution configuration file(s) Jul 29 15:54:46 usually they live in conf/distro/* with the main confgiuration selected by the DISTRO = value Jul 29 15:55:15 if you look at poky, you can find some examples Jul 29 15:55:16 http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-yocto/conf/distro Jul 29 15:55:22 thanks! Jul 29 15:56:05 in the poky case, 4 different distributions have been defined Jul 29 16:06:25 hi, the yocto sdk installs the environment setup script that in turn puts this into CXXFLAGS: -O2 -pipe -g -feliminate-unused-debug-types Jul 29 16:06:32 this is almost always wrong and not what a user wants Jul 29 16:06:56 is there an easy way to drop -O2 -g from there and let the SDK users decide about the optimization and debug levels? Jul 29 16:06:58 that's the same default flags that are used by the yocto build. no different in the sdk than in our builds Jul 29 16:07:56 I think it is saner for Yocto not to give any default Jul 29 16:08:04 otherwise it is difficult to append in software buildsystems Jul 29 16:08:42 in this case, override CXXFLAGS = ..., but if I use -O0 -ggdb for debug, the output will be cluttered even thoug I think it will pick up my override as that comes last in the command. Jul 29 16:08:55 though* Jul 29 16:09:09 presumably you could just override it entirely rather than appending to it, no? Jul 29 16:09:11 * kergoth shrugs Jul 29 16:10:45 I could, but the problem is that CXXFLAGS is not just about debug options. Jul 29 16:10:54 I would prefer keeping the default except the debug flags Jul 29 16:11:00 I do not think -O2 -g is sane Jul 29 16:11:05 it is not good for a release Jul 29 16:11:12 and it is not good for debugging either because of -O2 Jul 29 16:11:21 (not good for release because of -g) Jul 29 16:11:43 and I believe there is no sane default Jul 29 16:11:52 because any combination will make it difficult to nicely append Jul 29 16:12:01 I think this ought to be the sdk users in their software. Jul 29 16:12:07 up to* Jul 29 16:12:50 so as long as I can adjust it by some configuration, I will be happy. Jul 29 16:13:47 we don't use the flags variables for essential arguments like tuning, only for extra bits like optimizations and debugging. the only flag not related to those two is -pipe Jul 29 16:14:04 hmmm Jul 29 16:15:40 not sure if this is it: http://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#var-BUILDSDK_CXXFLAGS Jul 29 16:18:42 echo 'export CXXFLAGS="${TARGET_CXXFLAGS}"' >> $script Jul 29 16:18:49 from meta/classes/toolchain-scripts.bbclass Jul 29 16:19:07 so I believe it is enough to modify TARGET_CXXFLAGS in the distro conf then? Jul 29 16:19:13 to have it only, say: -pipe Jul 29 16:20:42 I eventually start thinking that the SDK cxxflags generated and the target flags to build for the target ought to be decoupled. Jul 29 16:20:46 they are not necessarily the same. Jul 29 16:21:04 although it is not unreasonable to have them the same either. Jul 29 16:21:10 like i said, it's using the same flags we use in our build, so yes, if you change the flags used in our build by altering TARGET_CXXFLAGS, yes, it would affect the sdk too Jul 29 16:21:15 ok, I am happy with this, so I have to override TARGET_CXXFLAGS. Jul 29 16:21:23 sure, thanks. Jul 29 16:21:29 you were right of course :) Jul 29 16:22:58 heh, wasn't looking for validation, just trying to explain :) but yes, i could see value in finding a way to expose our OPTIMIZATION variables independently. if you look at bitbake.conf, see SELECTED_OPTIMIZATION Jul 29 16:23:33 the problem of course is at the point the sdk is being emitted, TARGET_CXXFLAGS is one thing, its components aren't known, the variable is already expanded, so we'd have to filter out the optimization part and re-add it via the shell variable for the optimization Jul 29 16:23:54 but doable Jul 29 16:37:46 https://twitter.com/tom_gall/status/626415205342261252 Jul 29 16:37:49 ha Jul 29 16:46:00 * mario-goulart wonders why they didn't quote "roposotory" Jul 29 16:46:13 oops "reposotory" Jul 29 16:47:09 ergoth, umm.. wow Jul 29 16:47:17 "e-note"?! Jul 29 16:47:20 HAHAHAHAA Jul 29 16:47:35 wow.. Fox Business.. about as credible as Faux News Jul 29 16:48:55 http://www.youtube.com/watch?v=k2vJNNAQZlg is the video Jul 29 16:49:27 i'm thinking a roposotory must be a repository of rope Jul 29 16:58:11 kergoth: wow, thanks for sharing this :) Jul 29 16:58:20 :) Jul 29 16:58:29 a bit of humor for your wednesday Jul 29 17:01:29 Hmm, wonder if we should have a way to indicate packageconfigs which are required in particular contexts. libelf in rpm-native for example is required to get debugedit, which is required by our packaging Jul 29 17:09:53 wow, kergoth that really is tragic and hilarious at the same time. Jul 29 17:23:30 kinds folks, I am still struggling with getting touchscreen to work in core-image-sato. I have added the MACHINE_FEATURES "touchscreen" to beaglebone.conf, and verified that it gets picked up via bitbake -e core-image-sato. I created a machconfig file in meta/recipes-bsp/formfactor/files/beaglebone/ with the HAVE_TOUCHSCREEN=1 entry, which seems to have no impact on bitbake -e environment variables. Jul 29 17:26:29 dmesg shows no touchscreen input device, and I dont see included libs like tslib that should get picked up for the touchscreen MACHINE_FEATURE Jul 29 17:28:15 hi techs Jul 29 17:28:25 new to irc Jul 29 17:28:32 twirck-user-1320, presumably for your hardware there is a kernel .config option for the device ; might be worth checking if that is set and then if not, who you'd expect to set if for you and work backwards from there. Jul 29 17:28:56 at least that is how I'd do it, but then again I'm more a kernel person than a bitbake person. Jul 29 17:29:36 Q: is there a difference between using a blank do_compile() or no_exec[compile] = '1' ? Jul 29 17:31:43 thanks paulg. I will investigate kernel .config. The touchscreen is detected and comes right up with stock debian, so I should be able to use that to figure out which kernel modules are needed Jul 29 17:43:21 JaMa: what's the best bet for doing builds with an external toolchain whose binutils isn't patched to add armv5e support? revert the ARMPKGSFX_THUMB portion of fe66853/3e76003, or just override DEFAULTTUNE on a per-machine basis? Jul 29 17:44:49 qemuarm fails to build with meta-sourcery at the moment Jul 29 17:46:17 twirck-user-1320, yeah, i cant recall if we (yocto) enable /proc/config.gz by default, but if not you can find it in tmp/work/..../linux-yocto/4.1/.... Jul 29 17:46:25 (i.e. in the build dir) Jul 29 17:51:19 kergoth: can you give a bit more context about the binutils armv5e issue? Jul 29 17:52:03 gcc supports armv5e, but binutils doesn't. we carry a patch to add it, but upstream has rejected it Jul 29 17:52:16 thanks paulg, I dont see a .config anywhere in /tmp/work except for the following: Jul 29 17:52:20 ./cortexa8hf-vfp-neon-poky-linux-gnueabi/busybox/1.23.1-r0/sysroot-destdir/usr/lib/busybox/ptest/.config Jul 29 17:52:20 it's not being applied to binutils in the sourcery g++ builds at hte moment (though i might be able to ask them about that) Jul 29 17:52:43 so you need it to be armv5te? Jul 29 17:52:51 see meta/recipes-devtools/binutils/binutils/0007-Add-the-armv5e-architecture-to-binutils.patch Jul 29 17:52:54 i think that's the case, yeah Jul 29 17:53:39 that's why i asked you about it, since afaik you made it only add the t suffix when ARM_INSTRUCTION_SET isn't arm by obeying ARM_M_OPT. so was asking if is hould revert that in this case, or just override DEFAULTTUNE directly Jul 29 17:54:25 twirck-user-1320, so in the build I have laying around here, i've got tmp/work/genericx86_64-overc-linux/linux-yocto-dev/4.1-rc++gitAUTOINC+45393dd54f_1c72757dbf-r0/linux-genericx86_64-standard-build/.config Jul 29 17:55:19 yours will have a different path tmp/work//linux-yocto///.config Jul 29 17:55:30 * kergoth clearly isn't an expert on the arm tuning or instruction sets, hence the question Jul 29 17:55:41 linux-yocto vs linux-yocto-dev 'cause I'm using the development kernel Jul 29 17:56:45 twirck-user-1320, this assumes you've actually built a kernel and not reclaimed one from sstate or similar magic. Jul 29 17:57:01 tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14.36+gitAUTOINC+162dfe3bb0_dbe5b52e93-r0 is empty... Jul 29 17:57:06 kergoth: ok, so it's failing for you when building recipes which set ARM_INSTRUCTION_SET to arm, right? Jul 29 17:58:19 I think so, since in that case it'll try to pass -march=armv5e. I don't recall offhand which recipe was failing in particular, but gcc accepts it, then the assembler chokes Jul 29 17:58:21 kergoth: I'm a bit tired today, so excuse me, but I still don't see how binutils's as gets armv5e.. because IIRC my patches didn't change the CCARGs (or any *FLAGS) Jul 29 17:58:39 only made the TUNE_PKGARCH to match with the options used in the build Jul 29 17:58:46 TUNE_CCARGS=${@bb.utils.contains("TUNE_FEATURES", "armv5", " -march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}", "", d)}... Jul 29 17:58:51 it obeys ARMPKGSFX_THUMB Jul 29 17:58:54 for the -march Jul 29 17:59:08 so that ARM_INSTRUCTION_SET=arm recipe doesn't have "t" in PKGARCH Jul 29 17:59:23 aah.. Jul 29 18:00:08 right, that reminds me of this http://git.openembedded.org/meta-openembedded/commit/?id=c6c324c9044095c1cb93e4973d324e47f7e9e44e Jul 29 18:00:25 which is unintuitive, given the variable name is ARMPKGSFX_THUMB, explicitly mentioning PKG, but .. Jul 29 18:00:55 changing DEFAULTTUNE probably won't help, because DEFAULTTUNE only says which features are available for MACHINEs Jul 29 18:01:19 so ARM_INSTRUCTION_SET will still win (you can only disable thumb completely by selecting DEFAULTTUNE without thumb) Jul 29 18:02:37 you can also remove "arm" from TUNE_FEATURES to say that you never want to drop -mthumb (and "t" from ARMPKGSFX_THUMB), but that will break recipes which really fail to build with thumb Jul 29 18:03:49 so probably the best option would be to set only ARMPKGSFX_THUMB_armv5 in the tcmode*.inc file used by meta-sourcery with comment that binutils always expects armv5te even when building without -mthumb Jul 29 18:03:52 if -mthumb is removed, but march is armv5te rather than armv5e, will that work fine, indicating that thumb is available, we just aren't using it? Jul 29 18:04:06 okay, thats similar to what i was thinking Jul 29 18:04:10 i'll go that direction, thanks Jul 29 18:04:21 yes it should work Jul 29 18:04:39 that'll probably be a concern for any external toolchain, not just the sourcery one.. i should really separate what's specific and what's generic in meta-sourcery.. Jul 29 18:04:40 heh Jul 29 18:05:13 do you have some stats how many people are still interested in armv[456 Jul 29 18:05:16 ]*? Jul 29 18:05:26 so ARMPKGSFX_THUMB_armv5 = "${ARM_THUMB_SUFFIX}" should probably do it, i think Jul 29 18:05:28 hmm, not offhand Jul 29 18:06:08 we're using own external toolchain, but I was never hit by this issue, because we're building only armv7a Jul 29 18:06:24 ah, that makes sense Jul 29 18:06:43 twirck-user-1320, "bitbake -c configure linux-yocto" Jul 29 18:07:07 should populate that dir and get you a .config file Jul 29 18:08:48 re arm.. arm 4.. very few.. but there are still a few arm 920T designs.. armv5, I still see a lot.. not sure about 6 Jul 29 18:11:29 JaMa: actually, I get failures on more than just the ARM_INSTRUCTION_SET=arm recipes with qemuarm, even libtool-cross passes -march=armv5e and fails the do_configure compiler tests, as ARM_THUMB_OPT is arm whenever ARM_INSTRUCTION_SET isn't thumb, and i didn't set ARM_INSTRUCTION_SET globally to thumb. Jul 29 18:11:32 just as an fyi Jul 29 18:11:43 i wonder if we shouldn't move to newer arm instruction set with qemuarm at some point Jul 29 18:17:24 JaMa: btw, DEFAULTTUNE is viable without removing thumb if you don't need dsp, since armv5t == -march=armv5, which is supported by binutils upstream, it's just armv5e that isn't :) Jul 29 18:17:32 but the other solution is more general and is cleaner, so i'll do that :) Jul 29 18:21:54 paulg, strange, i ran bitbake -c configure linux-yocto, but never see a .config file generated. I did run "bitbake linux-yocto -c menuconfig", saved the file, and then ran "bitbake linux-yocto -c diffconfig" and get a good fragment file with the touchscreen modules, but I just never can find a .config being generated anywhere Jul 29 18:22:32 odd. not sure wtf is going on there. Jul 29 18:23:05 are you looking in ${S} rather than ${B}, perhaps? Jul 29 18:23:29 yeah, the kernel source is in work-shared, and the build is in work. Jul 29 18:23:56 folks are still getting used to that :) Jul 29 18:23:57 i take it back, I see a .config file here: tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14.36+gitAUTOINC+162dfe3bb0_dbe5b52e93-r0/linux-beaglebone-standard-build Jul 29 18:24:19 there you go, all is well with the world then. :) Jul 29 18:28:57 thanks paulg. reading the docs now to see how to incorporate my changes in the .config (or include the fragment) and rebuild kernel Jul 29 18:29:31 np Jul 29 20:27:25 It'd really be nice if task logging messages automatically included recipe and task name, so we don't have to do so manually, and inconsistently, in many cases. Jul 29 20:27:31 would be straightforward to implement.. Jul 29 20:27:58 could do it in the UI since we already associate messages with task ids, iirc, or in bitbake via a logging adapter/filter Jul 29 20:28:04 * kergoth ponders Jul 29 20:38:29 would be nice at least on the display side, since so many parallel activities can create a lot of output Jul 29 20:54:11 how would you do a conditional DEPENDS? Jul 29 20:54:27 could it be something like DEPENDS_foo and DEPENDS_bar? Jul 29 20:56:13 the same way you do conditionals anywhere else Jul 29 20:56:14 aehs29: if it's conditional on something in OVERRIDES yes, otherwise it would be DEPENDS = "${@,,,}" with a python expression inside Jul 29 20:59:21 i am trying to get local instance of toaster working in analysis mode, while I type local host and port in browser it gives 501 error, im using ubuntu 14.10 Jul 29 20:59:21 any idea what could be wrong Jul 29 21:00:21 i followed manual 3 times, still its ends up with same error, Am i missing some configuration ? Jul 29 21:06:51 bluelightning_: hmm, have you seen a `ln: invalid option -- 'r'` in install_tools in populate_sdk_ext? Jul 29 21:08:04 ah, i see. old host, it should be using poky's lnr script instead Jul 29 21:09:12 * kergoth tests that Jul 29 21:09:25 s/poky/oe-core/ Jul 29 21:18:27 https://github.com/MentorEmbedded/meta-sourcery/commit/140fed8a8391ea4d8fe397e4b39d869ed034bbb6 made me sad Jul 29 21:20:02 still not ideal, makes a number of assumptions. ideally, we'd probably name the packages based on the actual locale name rather than the name of the subdir in locales, or have it automatically rename the dir based on the locale name from LC_NAME or whatever that file is.. Jul 29 21:20:23 since afaict while the names of the subdirs might affect the list in `locale -a`, its their actual names in the files they include that controls when they're loaded Jul 29 21:21:04 I really need to stop the hardcoded SUPPORTED bits with external toolchains as well in favor of programmatically determining what locales are supported by it Jul 29 23:26:37 crap. X segfaults in libpthread with latest builds on master ; only on intel gfx though, it seems. Jul 29 23:27:20 diffing logs between my last known working binary and today's, i see this: Jul 29 23:27:23 -X.Org X Server 1.17.1 Jul 29 23:27:23 -Release Date: 2015-02-10 Jul 29 23:27:23 +X.Org X Server 1.17.2 Jul 29 23:27:23 +Release Date: 2015-06-16 Jul 29 23:27:39 ...should be fun to track down. :-/ Jul 29 23:28:44 lovely Jul 29 23:28:50 * paulg assumes from a yocto POV, this change came in as a single commit, so bisecting is out. Jul 29 23:34:40 presumably you could create a git recipe on the right tag, at each bisect adjust SRCREV to that? Jul 29 23:36:59 yeah, doing the google search 1st to see if anyone else has hit this already; if not I'll have to try sth like that tomorrow,. Jul 29 23:40:09 this looks similar ; will investigate more tomorrow. https://bbs.archlinux.org/viewtopic.php?id=175701 Jul 30 02:12:49 hmm, wonder what the status is of the ptests. last time i ran them on an image they exploded all over the place **** ENDING LOGGING AT Thu Jul 30 02:59:58 2015