**** BEGIN LOGGING AT Mon Oct 02 03:00:01 2017 Oct 02 06:56:23 good morning Oct 02 07:13:37 I have a question about "OVERRIDES" in bitbake Oct 02 07:13:57 in the manual, this OVERRIDES="arch:os:machine" Oct 02 07:15:26 so if i use TEST_arch = "foo" that means this will basically replaced by my assign value, right? Oct 02 07:15:44 as long as I've set this _arch variable? Oct 02 08:14:58 momofarm: TEST will take the value of TEST_arch if arch is in OVERRIDES, yes Oct 02 08:15:20 or can someone explain to me the bitbake evalutaion order when mutiple operator operate on same variable ex: A_foo_append Oct 02 08:15:41 this is really confusing Oct 02 08:16:06 bluelightning: thanks Oct 02 08:29:58 bluelightning: do you have any thoughts about this? http://lists.openembedded.org/pipermail/openembedded-core/2017-September/142893.html Oct 02 08:30:36 momofarm: A_foo_append would append if foo is in OVERRIDES Oct 02 08:30:45 bluelightning: in case we can move in #OE if you prefer Oct 02 08:31:13 momofarm: bitbake -e is useful to figure out how specific variables are being set (just pipe into less, not grep) Oct 02 08:32:18 so the evalution order is backward, right? Oct 02 08:32:41 momofarm: well, no, for simple assignment statements it's the order parsed Oct 02 08:33:01 momofarm: but _append and _prepend (and _remove) are deferred operations so they happen at the end Oct 02 08:33:09 append evaluate first, then if "foo" appears in OVERRIDE, it do override? Oct 02 08:35:31 so it's a delay evaluation operator Oct 02 08:35:47 momofarm: I don't think that's quite the way the code works but you pretty much just have to learn that its _append_ and not the other way around Oct 02 08:44:40 bluelightning: any recommend books better than the doc on website, it's kind of confusing Oct 02 08:45:43 momofarm: the bitbake manual covers the operations stuff but I guess that is what you have been reading Oct 02 08:46:18 bluelightning: yes, some part of this operator thing really confusing Oct 02 11:45:10 hi, I am trying to write a Makefile that builds fine for both arm and x86_64/i686 desktop. I would like that make (all) builds properly both with the Yocto generated SDK as well as inside Yocto when creating the image, as well as on my desktops. Oct 02 11:46:05 I can see that the Yocto SDK sets up the ARCH variable that I could check for, but there does not seem to be such a variable set up inside Yocto. There are MACHINE_ARCH, etc, though, so I could eventually check for more than one variable to be safe, but I am wondering whether there is one "build arch" variable that works both with the generated SDK as well as inside Yocto? Oct 02 12:00:16 seebs: how swamped are you now? would you be able to take https://bugzilla.yoctoproject.org/show_bug.cgi?id=11996 at some point? Oct 02 12:00:17 Bug 11996: normal, Medium+, 2.5 M1, alexander.kanavin, ACCEPTED , pseudo: cannot use unnamed temporary files (O_TMPFILE) Oct 02 12:33:42 Hi All, little question about patches. I'm doing 2 patchs for modifying the same file and they could be applying in the same time. For example, it's about a dts file. I would like to disabled/okay one of two node. So I've made a patch that can chance one of the node, and another patch for the other one. Oct 02 12:34:04 that can change* Oct 02 12:34:14 So i have two patch files. Oct 02 12:35:00 Is it a problem ? Oct 02 12:36:33 no, should be fine Oct 02 12:37:44 So the order i put into the .bbappend, will be the order to apply the patch. Oct 02 12:38:07 yep Oct 02 12:39:03 ok, i just need that when i apply the second patch, the line i would like to modify still be the same after the first one have been applied Oct 02 12:39:05 thanks. Oct 02 14:38:41 How is the prelink-cross package supposed to be used? Oct 02 14:54:02 armpit: morning Oct 02 14:54:20 sgw morn Oct 02 14:55:31 armpit: I am still trying to figure out the actual failure for that morty build, do you still have the AB log link? It's not in the bug Oct 02 14:55:57 kanavin: still pretty swamped but i can try to get a look. Oct 02 14:56:20 i'm in "yes, i'd like this done too, could you answer my questions about the requirements" land Oct 02 14:56:37 * armpit thought I added it.. Oct 02 14:56:45 * armpit checks Oct 02 14:57:57 seebs: I've done a stupid clueless patch, so you could maybe just comment on what's wrong with it (probably everything) Oct 02 14:58:15 I'll see if I can scrape some brain cells together. Oct 02 14:58:25 seebs: attached to the bug Oct 02 14:58:55 It looks like this should be reasonably straightforward to special-case, but what an awful API. Oct 02 14:59:28 There was already a defined way to use linkat() to make a new link to an unnamed file by file descriptor, why add another one? Probably because they hate me. :P Oct 02 15:01:08 sqw do you mean the stdio output ? Oct 02 15:02:57 the logs for that build did not land in wiki.. wiki was timing out that day Oct 02 15:03:01 https://autobuilder.yocto.io/builders/nightly-x86-lsb/builds/506/steps/Running%20Sanity%20Tests/logs/stdio Oct 02 15:03:53 i would have had new builds this morning but my build hung Oct 02 15:05:35 armpit: thanks, looking Oct 02 15:06:09 I add the log to the url link in the bug Oct 02 15:14:30 I have problem when doing bitbake -c populate_sdk . The image is a custom one that inherit from core-image-minimal. When I see the logs, he does lot of "make[x] : Nothing to be done" or "make[x]: Entering directory". Oct 02 15:38:15 armpit: so it appears that qemu just quit, maybe it could not find the right HW or something. This is a transient failure, we have not seen this multiples, correct? Oct 02 15:38:36 nope Oct 02 15:39:59 i could not reproduce it but the host was tumbleweed so wasn't sure if it was related to it Oct 02 15:44:14 armpit: thanks Oct 02 15:44:36 thanks for checking Oct 02 16:12:50 rburton: armpit: I think I am OK dropping the 12124 (qemu fails with Morty on a Tumbleweed host) priority to Medium from High. Unless we can get a more reproduible case Oct 02 16:13:25 ok Oct 02 16:13:29 agreed fwiw Oct 02 16:13:29 ok Oct 02 16:13:38 worth release noting? Oct 02 16:14:30 rburton: agreed Release note it, we can either keep the bug open or close it not sure Oct 02 16:17:10 sqw maybe wait for another build. this changes are not in morty yet. Oct 02 16:20:46 Any thoughts on https://github.com/openembedded/bitbake/compare/master...kergoth:gitsm-rework ? I still need to write some more unit tests to expand on the relatively weak existing coverage of it, and integrate it into the main fetcher, but could use another set of eyes on the code Oct 02 16:40:44 I have a already built project using yocto, right now there is a problem that I want to add everything to a git repository Oct 02 16:41:26 but the problem is inside yocto's directory, there is a kernel folder contains another hidden git directory Oct 02 16:42:02 the remote git server seems like can not accept another hidden git folder (for some reason) Oct 02 16:43:32 and after some reading, I found in yocto's kernel bb files there seems to have a lot of operation related to git (branch and something...) Oct 02 16:44:24 momofarm: what directory? Oct 02 16:44:30 is there a way that I can get rid that .git folder or there is / should be a better way to upload / freeze the built directory to remote Oct 02 16:45:06 rburton: a directory called kernel, and there is a linux kernel source code inside with a hidden .git foder Oct 02 16:46:01 momofarm: yeah don't put the tmp/ or download directory into git Oct 02 16:46:30 rburton: but if I remove that .git folder, the build process will fail Oct 02 16:46:52 seems like there is some operation related to that .git folder Oct 02 16:47:07 the files you add to a git repo should not include a kernel checkout Oct 02 16:47:30 if you are trying to put a kernel checkout into git then you are either adding DL_DIR (don't do that) or TMPDIR (don't do that either) Oct 02 16:48:56 but I need everything can be built off line, Oct 02 16:51:12 so have a local source mirror Oct 02 16:51:17 I need to keep kernel source local, so if next time we need to build something, we can just checkout from my server and build everything without to download from internet Oct 02 16:51:29 yes, that's exactly what a source mirror is for Oct 02 16:52:03 the path you set DL_DIR to is sharable. just don't put it in git, mainly because git is *terrible* for storing lots of large files. Oct 02 16:52:25 rburton: so if I have this local source mirror, then should I keep the kernel source folder? Oct 02 16:54:29 momofarm: https://wiki.yoctoproject.org/wiki/How_do_I#Q:_How_do_I_create_my_own_source_download_mirror_.3F Oct 02 16:54:51 then put your layers and so on in git. Oct 02 16:55:08 *do not* put your build/tmp/ into git as that will be a massive waste of time and space Oct 02 17:34:41 rburton, props to your experience. The permissions on the dir were 755 and 775 in two different RPMs, as you predicted. Oct 02 17:37:29 still a mystery why one package ends up installing the dir with 775 though. Some UMASK issue? Have no idea... I don't see it explicitly in any recipes. Oct 02 17:37:55 they run some special fakeroot job, which is doing the mkdir, that's all I can see Oct 02 18:12:32 rburton: did you see the lttng-modules? Oct 02 18:12:55 rburton: it is an important fix specially as people is using newer kernels with rocko Oct 02 18:13:26 rburton: 4.14 being a LTS is likely going to have a good adoption and it is important to be compatible Oct 02 18:44:42 armpit: did you see this? https://autobuilder.yocto.io/builders/nightly-x86-64-lsb/builds/516/steps/Running%20Sanity%20Tests/logs/stdio Oct 02 18:44:43 nightly-x86-64-lsb failed to start qemu on morty Oct 02 18:46:55 clsulliv, I have seen that issue before.. is this a new build? Oct 02 18:48:37 * armpit mmm tumbleweed again Oct 02 18:50:58 clsulliv, I first saw that on akuster/morty-next but now on morty Oct 02 18:51:04 bug 12124 Oct 02 18:51:05 Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=12124 normal, Medium, 2.2.3, akuster, ACCEPTED , [morty-next] nightly-x86-lsb failed Oct 02 18:53:33 * armpit hmm new build Oct 02 18:53:52 the last clean build I had was on commit http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=morty&id=a94a0c6402240ed02f364c87a5405f138634e46e Oct 02 18:54:25 there are 3 new ones past that I personnel have not run a build on Oct 02 19:04:48 otavio: lttng-modules: Backport fixes for kernel instrumentation? Oct 02 19:06:50 rburton: yes Oct 02 19:07:16 rburton: I'd prefer to upgrade but due the imminent release, backport makes more sense Oct 02 19:07:43 otavio: very high bar for 2.4.0 right now, but i have just picked it in the 2.4.1 queue (which depending on how RC1 QA goes may pick a few patches, or none) Oct 02 19:08:23 rburton: no problem; is master open for 2.5 material? Oct 02 19:09:27 well. 4.14 isn't even released yet, there's no guarantee that updating lttng-modules right now will ensure it works with 4.14 Oct 02 19:10:08 otavio: currently no, focus on 2.4.0 Oct 02 19:10:22 obviously i've been queuing stuff for master, i have a ross/sumo branch Oct 02 19:17:11 ntl: you're right but it fixes 4.13 that we use on meta-freescale, for example Oct 02 19:17:49 ntl: we are supporting new kernels on meta-freescale due the i.MX mainline support Oct 02 19:19:03 rburton: I have a cmake update ready to go Oct 02 19:19:13 rburton: also I have mesa update Oct 02 19:19:23 rburton: so once it opens, I can send it Oct 02 19:20:25 send them now if you want, they can go in my queue Oct 02 19:20:40 currently got ross/mut, ross/sumo and ross/rocko on the go :) Oct 02 19:23:12 rburton: ok; I send them tomorrow or so. So you have your test results before Oct 02 19:41:17 Hi! I started to scratch the surface of yocto and have the following question: why should IMAGE_FSTYPES go into local.conf and not in an image recipe? This in contrary to other variables like IMAGE_INSTALL which could apparently go in both. Oct 02 19:45:07 otavio, you there? Oct 02 19:45:12 I have to send you a bug report :) Oct 02 19:45:17 hello btw Oct 02 19:45:36 I'm doing a bitbake linux-mfgtool in my recipe Oct 02 19:45:38 ERROR: Nothing PROVIDES 'virtual/mfgtool-arm-poky-linux-gnueabi-binutils'. Close matches: Oct 02 19:45:38 virtual/arm-poky-linux-gnueabi-binutils Oct 02 19:46:05 I intercepted binutils-cross.inc with a bbappend PROVIDES += "virtual/${MLPREFIX}${TARGET_PREFIX}binutils" Oct 02 19:46:08 and now it works Oct 02 19:46:42 now, I don't know why MLPREFIX is there, but this seems to be an issue, because that recipe looks unbuildable as-is Oct 02 19:48:33 LocutusOfBorg: oh my God. Do you use MfgTool? Oct 02 19:48:41 LocutusOfBorg: poor you Oct 02 19:52:24 otavio, I'm sooo sorry Oct 02 19:52:26 :) Oct 02 19:52:41 but whatever who makes the board uses, I have to use it Oct 02 19:52:59 and two different board makers, use mfgtool already on i.MX6 Oct 02 19:53:08 never had to do something different Oct 02 19:56:38 anyhow, do you have any sort of bug-report or fixes that won't require a bbappend of binutils-cross? Oct 02 19:56:50 LocutusOfBorg: I use imx_usb for manufacturing Oct 02 19:57:00 which avoids the use of Windoze ;-) Oct 02 19:57:26 LocutusOfBorg: I don't. I will need to look at it Oct 02 19:57:36 LocutusOfBorg: are you in pyro or older release? Oct 02 20:04:45 pyro Oct 02 20:04:58 I always track the latest branch :p Oct 02 20:12:24 otavio: so the MfgTool is still in used? :p Oct 02 20:12:44 otavio: for parallel flashing I believe it is useful, isn't it? Oct 02 20:16:03 otavio: ok. FYI I've just bumped the lttng people to tag 2.9.4, they say they'll do it soon Oct 02 20:49:03 lsandov1: well, you can do it with imx_usb_loader ;-) Oct 02 20:50:33 otavio: right, even better Oct 02 20:53:07 LocutusOfBorg: I need to dig deeper. It is not something obvious ... Oct 02 21:28:47 I'm trying to create a new recipe for YP, I've used devtool to create it, now I would like to run up through the compile task, is there a way to just run some of the tasks with devtool, or a way to use bitbake to run a recipe that is managed by devtool? Oct 02 21:48:53 gwilson: assuming you aren't using devtool from inside the eSDK all the normal bitbake commands will work Oct 02 21:49:04 gwilson: e.g. bitbake -c compile recipename Oct 02 21:52:14 bluelightning: Yes, I just figured that out. I had been trying 'bitbake build recipe -c task', which didn't work. removing 'build' un-confusses bitbake. Thanks for the tip all the same. Oct 02 21:53:33 bitbake isnt' subcommand driven, devtool/recipetool are Oct 02 21:53:38 see also bitbake --help Oct 02 21:54:10 kergoth: thanks Oct 02 21:55:46 otavio, FWIW it was fine on jethro Oct 02 23:07:35 Is there a way to build a deb of an SDK? Oct 03 00:19:35 dushara: nothing built-in, you'd need to follow the debian packaging guide Oct 03 00:22:01 bluelightning: ok thanks **** ENDING LOGGING AT Tue Oct 03 03:00:00 2017