**** BEGIN LOGGING AT Thu Apr 09 02:59:58 2015 Apr 09 03:03:37 Guest66260, what type of image are you trying to build? Apr 09 03:11:01 redengin, the target is a small arm device that can run a minimal busybox root file system only. We launch an app and thats it. Apr 09 03:11:29 So QEMU is nice to test out that small system on the desktop. Apr 09 03:12:42 ah, so you don't want an arm toolchain in the device image Apr 09 03:13:45 which arm boot loader are you using? Apr 09 03:14:31 does qemu even run on windows? Apr 09 03:14:41 we have a simple hand written boot loader and also looking to see if u-boot will fit. Apr 09 03:15:56 I've built qemu for windows by myself a couple of times. A little annoying. They also have full pre-built packages for download. Apr 09 03:16:27 ah, cool Apr 09 03:16:45 It was more the idea of a one stop full SDK rather than an absolute must that Yocto build the windows QEMU. Apr 09 03:17:18 so what does your bootloader expect to find in order to boot? Apr 09 03:17:35 Actually I had thought if it wasn't already done I might try it as a learning exercise since I already have built it by hand. Apr 09 03:19:04 We partition the flash into a number of sections. kernel, device tree, squashfs RFS and app partition. Apr 09 03:19:36 so the boot loader copies kernel and RFS to RAM and jumps. Apr 09 03:20:31 we have it working on an older device but it's pretty limited. u-boot would offer some nice debug features. Apr 09 03:20:52 your bitbake output doens't include the kernel and a rfs? Apr 09 03:22:18 it puts the zImage and RFS under deploy/images Apr 09 03:22:46 we also want the SDK which is under deploy/SDK Apr 09 03:23:13 the image actually does not contain a compiler as the device is not big enough. Apr 09 03:24:03 the goal is only for the app partition to be built in Windows as the Yocto image is built obviously in Linux. Apr 09 03:24:29 But the build team wants the app build in Windows. Such a pain. Apr 09 03:25:12 And it would help to provide simple test qemu support in windows as well. Apr 09 03:31:40 Guest66260: I've been able to build QEMU with the meta-mingw layer before, there were some minor issues. Apr 09 03:34:39 nrossi, did you have to add extra configuration options to have the meta-mingw layer build qemu? Apr 09 03:34:54 it seems i had some patches for ncurses as well as hacks for dtc (although if you dont need fdt support in qemu you can just disable that) Apr 09 03:35:45 I just got done with a re-run of bitbake -c populate_sdk core-image-base and still no qemu in the SDK. Apr 09 03:35:55 try building "nativesdk-qemu" and see how far you get first. Apr 09 03:36:49 ya, when I actually built qemu on a Windows mingw environment, getting device tree support was a bear. Apr 09 03:37:05 I had to hack that build but it worked. Apr 09 03:37:42 I was hoping Windows qemu build done in Linux would actually not require that hack. Apr 09 03:37:50 and to get the populate_sdk to include qemu i think you need to add it to "TOOLCHAIN_HOST_TASK" Apr 09 03:38:09 if i remember correctly the hack was due to posix compliance of dtc Apr 09 03:38:20 and it was in the actual compiler and no in libfdt Apr 09 03:42:06 hmm, could be on the right path. It was trying to build a mingw qemu but died on an Xorg task. Bummer, I want to run nographics. Apr 09 03:42:45 ah I see you're trying to do a qemu build using the bitbake native toolchain Apr 09 03:43:31 Oh one other thing, you cant build qemu for mingw64, you have to target 32-bit. QEMU has a hard limitation on that one Apr 09 03:44:47 I can live with 32-bit, I did specify 64-bit but suspected it would cause trouble. Apr 09 08:27:51 morning all Apr 09 08:28:00 morning Apr 09 08:28:48 I'm a bit confused by the runqemu and runqemu-internal scripts Apr 09 08:28:52 http://codepad.org/wlSiwUQP Apr 09 08:29:20 rahc: yer they are not much fun :P Apr 09 08:29:21 runqemu-internal has support for a "qemuarmv7" MACHINE but runqemu does not Apr 09 08:29:57 nrossi: would you accept patches to make runqemu support "qemuarmv7"? Apr 09 08:30:31 or even make it a bit more nuanced, like being able to specify appropriate options for "-cpu", like cortex-a8 or cortex-a9 Apr 09 08:30:38 I want to emulate a cortex-a9 Apr 09 08:31:11 im not the maintainer, i've just had many a war with those runqemu scripts :P Apr 09 08:31:37 maintainers: would you accept patches to make runqemu support "qemuarmv7"? :-) Apr 09 08:31:52 you can always submit it, i dont see any particular reason for it not being accepted Apr 09 08:38:36 I think we'd probably accept it Apr 09 08:38:48 we're probably overdue to implement a proper extension mechanism for runqemu though Apr 09 08:39:30 having said that, qemuarmv7 would probably be most appropriately supported within OE-Core even if that were in place Apr 09 09:55:17 ping kergoth Apr 09 10:30:02 hi, can I get some help with "oe-init-build-env-memres"? I do not know the use case for it and it does not seem to be documented either. Apr 09 10:30:20 http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#structure-memres-core-script -> it is sort of explaining what it does, but it does not explain why. Apr 09 10:46:24 lpapp: you save a bit of time on repeated bitbake invocations because it's in memory Apr 09 10:47:30 lpapp: there are issues with detecting metadata changes while running it though (until recent fixes in master, which *may* be backported to dizzy) Apr 09 11:05:25 bluelightning: ok, I am updating from dylan to daisy Apr 09 11:05:50 and this memres turned up, but then we possibly do not need it as memory is not a big deal on powerful build machines, is it Apr 09 11:06:27 well, it's not about that, it's about whether you are bothered by the time bitbake normally takes to start up Apr 09 11:06:35 personally I put up with it Apr 09 11:07:09 but to be honest I would advise against using memres until 1.8 (fido) Apr 09 11:07:29 (or when the inotify patches get merged to dizzy, if that happens) Apr 09 11:10:55 ok, thanks. Apr 09 11:11:34 Hey whats the recepy name for Yocto-KERNEL-HEADERS? Apr 09 11:11:42 or Core-Devel-Tools Apr 09 11:11:43 ? Apr 09 11:12:02 also...is there a Yocto apt-get recepy I can add? Apr 09 11:41:53 I know I can find out the dependencies of a package with the bitbake -g option, can I also somehow find out how this dependency is introduced? I have several recipes that are always rebuilt when I change something in one specific recipe, but I don't know where this dependency comes from Apr 09 11:54:10 are you looking for a dependency graph? Apr 09 11:55:19 no, I am looking for the step after having the dependency graph, to find where this dependency originates Apr 09 11:56:11 ok, so that you do not have to anything more than just reading a chain. I doubt that as it is quite specific need, but cannot you cook a simple script? Apr 09 12:07:10 sorry for beeing unclear, I know that a bunch of recipes depend somehow on recipe2, but I have no clue where this is introduced in my layers Apr 09 12:07:52 now I'd like to find out what creates that dependency Apr 09 12:21:36 jaeckel: I usually search the graph for '-> the-dependency-name' Apr 09 12:21:50 yeah I searched where the discovery came from Apr 09 12:22:14 now I saw that this is caused by VIRTUAL-RUNTIME_initscripts = "recipe2" Apr 09 12:22:48 and this variable is automatically used in DEPENDS Apr 09 12:24:21 Hey guys how can I download the Yocto kernel headers? Apr 09 12:26:02 is there some documentation where I can see what VIRTUAL-RUNTIME_initscripts is intended to be used for? Apr 09 12:26:26 cart_man: can you explain the context of the question? what are you trying to do? Apr 09 12:27:35 jaeckel: I don't believe we have that documented, but basically it's a placeholder for what the initscripts package normally contains - if you don't need it, just set it to nothing Apr 09 12:28:20 bluelightning,Im trying to write PCI drivers Apr 09 12:28:23 so if I make sure that this recipe is included somewhere else in the build process there is no need to set it there? Apr 09 12:28:26 and I need the Kernel headers Apr 09 12:28:49 usually in Ubuntu it will be apt-get install kernel-headers Apr 09 12:29:11 but I cant get apt-get in Yocto so I have no idea how getting then is possible Apr 09 12:30:48 cart_man: kernel-dev would be the package name but to be honest I wouldn't have thought doing this kind of development on the target would be the way to do it... Apr 09 12:31:03 cart_man: it's also going to depend on what machine you are targeting Apr 09 12:32:34 Well the chipset determines the sort of kernel right? Apr 09 12:33:13 Ghez I have idea where to even begin searching for it Apr 09 12:35:24 cart_man: my advice would be to find the appropriate BSP for the machine you are targeting (BSP = Board Support Package, i.e. how our build system knows how to support a particular piece of hardware) Apr 09 12:35:52 then, build the kernel and you will get the kernel headers as part of that process Apr 09 12:36:07 we have a kernel development manual: http://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html Apr 09 14:13:08 bluelightning: are you still about? Apr 09 14:14:50 bluelightning: I am getting this after copying the daisy directories over, TEMPLATECONF=meta-foo/conf . oe-init-build-env Apr 09 14:14:53 /home/lpapp/Projects/foo/Yocto/poky-dylan-9.0.1/scripts/oe-setup-builddir: 44: .: Can't open /home/lpapp/Projects/foo/Yocto/poky-dylan-9.0.1/.templateconf Apr 09 14:18:09 lpapp: not sure, it's not a known bug AFAIK Apr 09 14:27:26 bluelightning: sure, it is pebkac, thanks. Apr 09 14:27:41 I did not copy that file over, I thought oe-... bitbake, meta and scripts would be enough Apr 09 14:27:49 apparently, I need that "hidden" file, too. Apr 09 14:30:02 is there any other files that I forgot to copy over? Apr 09 14:30:33 not that I am aware of Apr 09 14:32:26 bluelightning: thanks, this is odd for bitbake myimage, https://paste.kde.org/pmw3pqiyf Apr 09 14:34:00 proxy settings set correctly? Apr 09 14:34:37 our network is working with dylan. Apr 09 14:35:15 all that check does is try to fetch some dummy data from yoctoproject.org Apr 09 14:35:20 using bitbake's fetcher Apr 09 14:37:09 strange. Apr 09 14:37:20 because there are no problems with dylan, only now with daisy. Apr 09 14:40:29 does this operation depend on some config? Apr 09 14:52:49 lpapp: nothing that the fetcher doesn't use - the implementation is check_connectivity() in meta/classes/sanity.bbclass Apr 09 15:01:15 has that changed between dylan and daisy? Apr 09 15:02:50 git blame says that function itself hasn't changed materially since 2011 Apr 09 15:04:05 it's a bit annoying that it doesn't actually report the failure Apr 09 15:04:36 yaeh :/ Apr 09 15:04:39 perhaps you can patch that? Apr 09 15:07:39 bluelightning: I guess I will need to put debug statements into that file then or shall I try something simpler? Apr 09 15:08:27 lpapp: that's really the only way to determine what's going wrong at this point Apr 09 15:25:28 bluelightning: shall I raise a report for making the error reporting better for this? Apr 09 15:32:22 bluelightning: we have some internal mirrors for downloading the software should that be an isuse. Apr 09 15:32:25 issue* Apr 09 15:34:27 lpapp: yes please file a bug for the error message Apr 09 15:35:02 bluelightning: ok, but have you checked it in the latest version? It is from daisy. Apr 09 15:35:40 lpapp: I doubt I would have experienced the same issue here, so it's not something I can test - I suspect it's specific to your setup Apr 09 15:36:18 seems the latest is verbatim Apr 09 15:52:45 bluelightning: we have our own SOURCE_MIRROR_URL = "http://foo/yocto/downloads" Apr 09 15:52:50 could that be the issue? Apr 09 15:54:45 it is in our distro/foo.conf Apr 09 15:58:54 bluelightning: I also have CONNECTIVITY_CHECK_URIS Apr 09 15:58:54 lpapp: wouldn't have thought so, SOURCE_MIRROR_URL sets (PRE)MIRRORS, but that check function unsets PREMIRRORS and MIRRORS in order to really test whether network connectivity is working Apr 09 15:59:14 https://paste.kde.org/pjspf8spa Apr 09 16:00:07 lpapp: right, that's the default value... Apr 09 16:00:34 yes Apr 09 16:03:29 hey all, I'm having issues with a Python error in the SDK...I've installed nativesdk-python-modules, but I still get this error everytime I source the env script and try to run a python script (or run a program that doesn't exist, for some reason) Apr 09 16:03:30 File "/opt/poky/1.7.1/sysroots/x86_64-pokysdk-linux/usr/lib/python2.7/sysconfig.py", line 10, in Apr 09 16:03:31 'stdlib': '{base}/'+sys.lib+'/python{py_version_short}', Apr 09 16:03:31 AttributeError: 'module' object has no attribute 'lib' Apr 09 16:04:32 the strange thing is, the line that generates the error calls "sys.lib", which was added in multilib.patch...and the patch is being applied correctly....is very strange Apr 09 16:05:24 ebolton: I meant to reply to your email - I honestly don't know what could be going wrong there :( Apr 09 16:08:11 ebolton: is nativesdk-python-modules *definitely* part of the SDK now? your email was suggesting that that wasn't working Apr 09 16:11:59 bluelightning: yea, I realized after I wrote that email that nativesdk-python-modules was actually an empty package that the python recipe generates as a "catch all" for the rest of the module packages....so I was looking for a dir in the workdir that didn't exist....so I checked the SDK sysroot after I installed it and all the modules are in /usr/lib/python2.7 Apr 09 16:12:47 ebolton: ah ok, at least that's dealt with Apr 09 16:15:11 @bluelightning: what's weird is the error itself isn't in a module....that multilib patch touches the core Python code directly...all the code its looking for is there, and as far as I can tell PYTHONHOME is set correctly Apr 09 16:16:09 yeah... I'm assuming "sys" is not actually meant to be the sys module at that point in the code Apr 09 16:17:00 bluelightning: https://bugzilla.yoctoproject.org/show_bug.cgi?id=7592 Apr 09 16:17:01 Bug 7592: normal, Undecided, ---, cristian.iorga, NEW , No detailed explanation of a sanity checker connectivity issue Apr 09 16:18:09 well, "import sys" is used in the code...so sys is technically a module I think....but just part of core Python....it's not in the extra modules packages Apr 09 16:18:49 bluelightning: I could probably get along by wiping that list out? Apr 09 16:19:00 or just simply disabling the sanity check? Apr 09 16:19:14 lpapp: did you put the debug message in to find out which URL was failing to fetch and how? Apr 09 16:21:07 bluelightning: nope, I guess I would need to put that into Fetch? Apr 09 16:21:38 lpapp: I would have thought you could just print the exception or not catch it Apr 09 16:27:32 bluelightning: Fetcher failure for URL: 'git://git.yoctoproject.org/yocto-firewall-test;protocol=git;rev=HEAD'. The command git ls-remote git://git.yoctoproject.org/yocto-firewall-test refs/heads/HEAD refs/tags/HEAD^{} gave empty output unexpectedly Apr 09 16:28:32 lpapp: which version of git are you using? Apr 09 16:29:46 git version 1.7.10.4 Apr 09 16:30:42 ebolton: hmm, so it looks like sys.lib should be valid for the patched python that we build but isn't part of the standard python API Apr 09 16:31:04 ebolton: maybe some kind of mixture of the system python and the libs within the SDK is happening? Apr 09 16:32:47 ebolton@debian:~/yocto/outbacks4$ which python Apr 09 16:32:48 ebolton@debian:~/yocto/outbacks4$ env | grep PYTHON Apr 09 16:32:48 PYTHONHOME=/opt/poky/1.7.1/sysroots/x86_64-pokysdk-linux/usr Apr 09 16:32:48 ebolton@debian:~/yocto/outbacks4$ Apr 09 16:33:11 git version 2.3.5 on my Archlinux, but that is irrelevant now as I run Yocto on Debian 7.7. Apr 09 16:33:59 bluelightning: sorry, copy/paste spam :) PYTHONHOME looks correct, and it's using the SDK python, not the system one Apr 09 16:34:09 bluelightning: not sure what else to check Apr 09 16:34:20 lpapp: hmm, that's odd... that git ls-remote command here returns empty Apr 09 16:34:47 and yet the sanity check passes... Apr 09 16:35:07 bluelightning: odd Apr 09 16:35:16 so what can I do to proceed? Apr 09 16:36:03 ebolton: "which python" returns nothing? Apr 09 16:36:25 bluelightning: no, not sure why that happened Apr 09 16:36:36 ebolton@debian:~/yocto/outbacks4$ which python Apr 09 16:36:44 bluelightning: I do not even see a sanity (insane) option for disabling this. I am checking the YRM. Apr 09 16:36:54 http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#ref-classes-insane Apr 09 16:37:02 "/opt/poky/1.7.1/sysroots/x86_64-pokysdk-linux/usr/bin/python" Apr 09 16:37:11 lpapp: that's insane.bbclass, not sanity.bbclass, two different thing Apr 09 16:37:15 s Apr 09 16:37:20 fair enough, thanks. Apr 09 16:37:33 bluelightning: apparently HexChat doesn't like lines starting with a slash :) Apr 09 16:38:01 so what are my options with this to get along? Apr 09 16:38:05 ebolton: oh, right - yeah IRC wouldn't, those are assumed to be commands Apr 09 16:38:12 remove that entry for the uris variable? Apr 09 16:38:19 lpapp: you could try that, sure Apr 09 16:38:35 it is not a nice "solution" though. Apr 09 16:38:54 it would be nice to know what and why exactly it fails. Apr 09 16:39:00 it would be Apr 09 16:39:18 without a reproducer though there's not a lot I can do on my end, if you could help track it down that would be very helpful Apr 09 16:39:18 we should really enhance sanity.bbclass to support insane-like control over what tests are run, like ERROR_QA & friends Apr 09 16:39:49 kergoth: it's not quite the same situation though... tests that fail there should never fail unless there is something really wrong Apr 09 16:40:26 whereas insane tests are applied across a wide variety of recipes and can often false-positive Apr 09 16:41:28 hmm, true Apr 09 16:41:53 ebolton: are you building from the dizzy-1.7.1 release or a recent version of the dizzy branch? Apr 09 16:42:57 bluelightning: I "git pull" from dizzy every week or so....not building from the tagged 1.7.1 release Apr 09 16:43:15 bluelightning: can you help me with tracking it down? I do not even know where to start, but I can follow any hints if they are not very time consuming. Apr 09 16:46:28 lpapp: AFAIK the only parts of the code involved with this failure ought to be the function in sanity.bbclass, and the fetcher i.e. bitbake/lib/bb/fetch2/__init__.py and bitbake/lib/bb/fetch2/git.py Apr 09 16:48:19 do you know which command exactly it runs underneath or is that something to be figured out yet? Apr 09 16:49:18 in theory it's the one called out in the error, i.e. git ls-remote git://git.yoctoproject.org/yocto-firewall-test refs/heads/HEAD refs/tags/HEAD^{} Apr 09 16:52:36 perhaps I should run that manually? Apr 09 16:58:40 you could certainly try Apr 09 16:59:26 empty output Apr 09 16:59:34 return code is zero, which indicates success Apr 09 16:59:38 so what is Yocto's issue? Apr 09 17:01:57 I guess I will need to understand how exactly Fetch works? Apr 09 17:05:05 have a look at the git fetcher, specifically the bit that's actually doing the ls-remote Apr 09 17:31:10 Is there any way to keep two version of shared library in filesystem using yocto Apr 09 17:33:13 When using package revision only one library which is updated will present in fs. Apr 09 17:33:40 But i wanna keep both old and new libs in fs Apr 09 17:33:49 Any ideas? Apr 09 17:36:59 Guest58084: you'd need two separately named recipes producing packages that did not install conflicting files in order to achieve that Apr 09 17:40:32 Thanks. But the old lib i am not going to update. Only the new lib is get update in git source. Apr 09 17:41:18 I will compile the first lib at some fixed git tag and new lib from latest git tag. Apr 09 17:43:08 sure, but you still need two recipes producing separate packages for that Apr 09 17:50:49 bluelightning: well, perhaps if the command returns empty output for you, you could print out the output variable in the git.py function? Apr 09 17:51:02 to see what it returns to you? It returns empty for me just as on the command line, manually. Apr 09 17:51:19 this line: output = runfetchcmd(cmd, d, True) Apr 09 18:06:30 bluelightning: and anyway, is that command supposed to return empty output or some valid content? Apr 09 18:20:45 bluelightning: it makes me think that you do not get the same cmd in the code as I do. Apr 09 18:20:52 as my command returns empty for everyone that I talked to. Apr 09 18:21:04 would it be possible for you to print out your command? Apr 09 18:22:10 lpapp: ok, so finally I just found that the git URL was removed from CONNECTIVITY_CHECK_URIS back in 2012 Apr 09 18:23:24 but daisy was coming out later, no? Apr 09 18:23:52 yeah Apr 09 18:24:06 so I do not get the issue then. Apr 09 18:24:11 did you by chance copy an older poky.conf and then modify it, hence you have the old value? Apr 09 18:24:25 yes, from the dylan times. Apr 09 18:25:05 but even that was released only two years ago Apr 09 18:25:46 I wonder if it is an inheritage from our early denzil variant. Apr 09 18:25:53 most likely Apr 09 18:25:59 it seems that we need to update the config at each release based on how poky proceeds. Apr 09 18:26:15 yeah, I am unsure because I thought that I redid this for dylan. Apr 09 18:26:22 not using any of denzil during the migration. Apr 09 18:26:26 well, I wouldn't necessarily say that, if you follow the migration guide that ought to be enough Apr 09 18:26:55 in this instance it appears something broke with how that particular URL is handled in that context and since we dropped it from the checked list nobody noticed Apr 09 18:26:56 was this mentioned in the migration guide? Apr 09 18:27:05 no, see above Apr 09 18:27:24 hmm Apr 09 18:27:26 I strongly suspect this is a bug rather than something that needs to be worked around Apr 09 18:27:37 the key is probably the rev= Apr 09 18:27:42 oh? Apr 09 18:28:24 I don't think that's commonly used in normal usages of the git fetcher (i.e. SRC_URI within recipes) Apr 09 18:29:56 ok, well, would you like to see another report? And as for the time being, I guess I could just remove that url. Apr 09 18:31:04 if you don't mind filing it, sure Apr 09 18:31:45 though if you do it would be worth adding a clarifying comment to the earlier bug that the actual issue is covered by the new one Apr 09 18:32:30 I think it is still useful to print the exceptions as a separate issue. Apr 09 18:34:32 yeah I agree, it's just that reading over the report it kind of reads as if it's about both fixing the error and the error message (which I guess it was at the time) Apr 09 18:36:30 ok, hmm, now I am getting this >_< https://paste.kde.org/pqcvlfle5 Apr 09 18:40:30 have you done anything to that recipe? Apr 09 18:40:58 nothing Apr 09 18:41:10 I copied meta over from the poky daisy release into our repository. Apr 09 18:41:19 so it oughta be verbatim. Apr 09 18:41:32 but I can paste the content just in case if you like. Apr 09 18:41:33 it's probably old... that is covered in the migration guide btw (bb.which -> bb.utils.which) Apr 09 18:41:59 whereever you have that, that is Apr 09 18:42:05 strange. Apr 09 18:42:16 I thought the meta layer in daisy was supposed to just work? Apr 09 18:43:05 I guarantee that reference was not part of the daisy metadata, it must come from something you have left over Apr 09 18:43:27 where exactly? How can I pin that down? Apr 09 18:43:34 grep for it? Apr 09 18:44:18 where can I find the migration guide? https://www.yoctoproject.org/downloads/core/daisy161 Apr 09 18:44:26 I cannot seem to find the YRM in there. Apr 09 18:46:41 hello ! I have a recipe, with a git URI, and I'd like know in what directory the the git is cloned, thank you ! Apr 09 18:47:05 http://www.yoctoproject.org/docs/1.6.1/mega-manual/mega-manual.html Apr 09 18:47:15 nvm, I have just looked for the word "migration" in the mega manual. Apr 09 18:49:30 http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#migration Apr 09 18:49:59 acidfu: ${WORKDIR}/git Apr 09 18:50:16 at least, that's where it's finally cloned to Apr 09 18:57:50 ok great ! Apr 09 19:08:39 bluelightning: Is there wiki doc on how to use locked sstate practically Apr 09 20:57:39 hey all, is there any way to add a build time dependency to a recipe from local.conf? I'm building Qt, which depends on the OpenGL ES headers, which are being provided by a separate recipe for the graphics driver... Apr 09 20:58:36 the driver is listed as the provider for virtual/opengles2, but it's not being built before Qt for some reason Apr 09 21:35:34 pidge: I made the fido branch for meta-fsl-arm Apr 09 21:35:49 otavio, ty! Apr 10 00:33:01 hmm Variable SRCPV value changed from 'AUTOINC+3ae139ecd8' to '3ae139ecd8' Apr 10 00:33:14 how could that be ? Apr 10 00:44:37 my PV = "1.99+gitr${SRCPV}" Apr 10 00:44:47 SRCREV = "${AUTOREV}" **** ENDING LOGGING AT Fri Apr 10 02:59:59 2015