**** BEGIN LOGGING AT Mon Dec 01 02:59:58 2014 Dec 01 05:20:19 what is the default install folder for opkg? Dec 01 08:13:45 good morning Dec 01 09:30:55 bluelightning: hey Dec 01 09:31:04 morning all Dec 01 09:31:06 morning lpapp Dec 01 09:31:15 bluelightning: what is the best way to debug sstate cache related issues? Dec 01 09:31:35 lpapp: what's the issue? Dec 01 09:34:25 bluelightning: it is taking me 40 minutes to rebuild our image from scratch, but my colleague is telling me that it takes about 1-2 hours for him just to clone the linux kernel repository from upstream. Dec 01 09:34:39 bluelightning: we have about the same machines, so there is no gap in there to think about. Dec 01 09:34:48 everything is pushed to our local mirror. Dec 01 09:35:11 that sounds like multiple issues though Dec 01 09:35:17 why git and not a tarball? Because it is easier to apply git formatted patches. Dec 01 09:35:39 assuming there are no obvious configuration differences there's perhaps the issue of sstate not being reused Dec 01 09:35:54 but taking 1-2 hours to clone, that's not sstate at all Dec 01 09:36:04 we are aiming for identical configs. Dec 01 09:36:32 we may disable rm_work when we need to debug, but that is the only thing I can think about, or the -j8 vs. -j16 thing. Dec 01 09:37:19 the upstream linux repository is huge, but I thought sstate cache would allow us not to clone it, just fetch the already cloned repository from the local mirror. Dec 01 09:38:14 you have a fixed SRCREV that is a full hash for that kernel recipe, right? Dec 01 10:22:55 Hi! I try to build QtWebEngine 5.4.0-beta1 with a modified version of the meta-qt5-Recipe. I get strange python errors like this during bitbake: https://paste.ee/p/WgFvG whenever one of the build scripts in the chromium submodule is using subprocess. Any ideas what might be the cause? Dec 01 10:25:23 I am able to run these scripts with the sysroot python executable from the commandline, but not within the bitbake build process. Dec 01 10:25:38 what are the modification? Dec 01 10:25:39 s Dec 01 10:27:31 Only changing the commit to the 5.4.0-beta1 tag for all the necessary git recipes. Dec 01 10:28:58 A previous version of QtWebEngine from the 0.9 branch is building fine, but not the 5.4-version. Dec 01 10:30:35 why don't you use newer meta-qt5 which also has newer version of qtwebengine? Dec 01 10:30:44 there is 1.0 in current master branch Dec 01 10:30:58 and I've sent patch for 5.4-rc1 to ML (still testing that) Dec 01 10:35:06 I tried the current master recipe for qtwebengine, but the problem seems to be that, it still points to the 1.0 branch, that has been renamed to 5.4 and it also pulls in chromium 33 and not chromium 37 that is used with current qtwebengine afaik. Dec 01 10:35:19 hey! Is there a way to ask bitbake to *not* git pull in each repo when running? (and so save us from rebuilding a lot of components) Dec 01 10:35:40 So I decided to switch all the recipes to beta1 for a stable build Dec 01 10:36:00 frsc: 11:31:00 < JaMa> and I've sent patch for 5.4-rc1 to ML (still testing that) Dec 01 10:36:41 cassidy: it'll only do that if you don't have a fixed full hash in SRCREV within the recipe Dec 01 10:36:58 bluelightning, yeah that's the case Dec 01 10:37:12 frsc: this patch is already in master-next and beta1 recipes are already in master (except qtwebengine) Dec 01 10:37:18 bluelightning, but in my case I'd just like to generate a new image to test some changes without rebuilding the world Dec 01 10:38:01 cassidy: so perhaps I'm not following - what are you changing exactly? Dec 01 10:39:30 bluelightning, let's say I make a change in a recipe. Then I'd like to generate a new image so I can test this change. Atm bitbake will git pull for *each* component and so rebuild a lot of things. While I just want the component of the recipe I changed to be rebuild and the new image generated. Dec 01 10:43:02 JaMa: Thank you! I didn't look into master-next. I'll try to build this and see if rc1 works. Dec 01 10:43:57 cassidy: I could be wrong, but I think what you are seeing is a change to signatures in one recipe cascading to components that depend on the recipe that was changed Dec 01 10:44:33 cassidy: that shouldn't translate to an actual git pull provided that the SRCREV is fully specified, but it might still run do_fetch Dec 01 10:47:47 bluelightning, sorry for the confusion, I meant that the SRCREV is *not* fully specified, so the expected behaviour is indeed to fetch and build from HEAD. But in some cases I'd like to disable this to speed up the build. Dec 01 10:51:44 cassidy: ah, right... in that case, you could set SRCREV to the full hash you want to build in the recipe or a bbappend, or alternatively use SRCREV_pn- = "" in local.conf Dec 01 10:52:26 bluelightning, yeah but that means I'll have to do that for each component right? Dec 01 10:52:47 cassidy: yes Dec 01 10:53:03 cassidy: if you have buildhistory enabled there is a helper there which can collect the last built SRCREV values though Dec 01 10:53:17 bluelightning, that's not really going to scale. :\ I was hoping for a bitbake command line argument or something Dec 01 10:53:58 http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#build-history-package-information Dec 01 10:54:08 (look for buildhistory-collect-srcrevs) Dec 01 10:54:45 unfortunately there is no quick shortcut for this since without somewhere to get those values (buildhistory or the recipe itself), the build system doesn't have them anywhere Dec 01 10:55:18 I see, too bad. Thanks for your help anyway :) Dec 01 11:02:09 has support for mx25 - specifically target karo tx25 been dropped in yocto? can't seem to find conf files for either Dec 01 11:20:04 otavio: hi Dec 01 11:20:35 otavio: so would it be yourself or someone else at your firm as maintainer (or multiple?) Dec 01 11:23:41 bluelightning: it could be Mario and myself; mario-goulart? Dec 01 11:24:18 otavio: ok, thanks, I'll send some email Dec 01 11:26:14 * mario-goulart Dec 01 11:26:25 otavio, bluelightning: alright! Dec 01 12:00:37 Hi dv_, I'm trying Chromium with your chromium-imx patches and getting the following when playing a HTML5 video on a custom i.MX6-Board: https://paste.ee/p/A0R7d. Maybe you have an idea what's wrong? Dec 01 12:00:37 I only got 256M RAM, so this might just be not enough, but maybe there's also something else I'm missing!? Dec 01 12:34:33 bluelightning: yes Dec 01 12:45:01 bluelightning: so how can I debug this sstate cache issue if I use a hash for SRCREV? Dec 01 13:36:17 lpapp: I would suggest comparing the sigdata files from the stamps directory for the earliest task you can find that executes on the other machine using bitbake-diffsigs Dec 01 13:39:40 bluelightning: find ./sstate-cache/ -name \*sigdata\* returns empty, so I probably do not know what a sigdata file is. Dec 01 13:40:03 lpapp: stamps directory Dec 01 13:40:22 lpapp: tmp/stamps, not sstate-cache (although the siginfo files in the sstate-cache are similar, but they are limited to only sstate tasks) Dec 01 13:56:17 JaMa: I just tried the master-next branch of meta-qt5 and the build of rc1 and I had to change md5 checksums for qtwebengine. Also qtwebengine build for linux-oe-g++ is blocked by isPlatformSupported in functions.prf. After changing that I still have the python subprocess problem described earlier: https://paste.ee/p/WgFvG Dec 01 13:57:09 bluelightning: ok, requested that from my colleague (boss). Dec 01 13:57:51 frsc: md5 checksums? it's fetching from git Dec 01 13:59:39 frsc: and please send patch for isPlatformSupported in functions.prf Dec 01 14:04:28 JaMa: I mean the LIC_FILES_CHKSUM for the license files Dec 01 14:11:35 sgw_, RP: We have a recipe that wants to run c_rehash during make install. In 85ac39431a you changed ho c_rehash is installed and modified the first line using sed to be #!${bindir}/env perl. The problem now is that when this openssl-native installs this the first line expands to something like: #!/home/pkj/yocto/builds/porky-p3367/tmp/sysroots/x86_64-linux/usr/bin/env perl but there is no env command at that location... Dec 01 14:19:50 Saur: sounds like this should be something which is only target specific Dec 01 14:21:32 RP: Looking in tmp/sysroots/x86_64-linux/usr/bin, I find no perl, but only a nativeperl. What's the idea behind that? Dec 01 14:22:03 Saur: I haven't looked at the commit but I suspect on the target it was expanding to a build path Dec 01 14:22:42 RP: For target build I guess it would have expanded to the expected #!/usr/bin/env perl... Dec 01 14:26:26 RP: Hmm, is there a good way to check whether we are doing a native build from within the do_install shell code? Dec 01 14:39:54 frsc: ah possible, I've bumped SRCREV again today and haven't finished building it yet Dec 01 14:40:30 Saur: often, do_install_append_class-target is used Dec 01 14:47:08 RP: Does this look about right then http://pastebin.com/ZAw1tnDS ? It will leave the first line as is for native/nativesdk builds (i.e., as #!/usr/bin/env perl). I am not sure that is correct, or if it should be changed to #!/usr/bin/env nativeperl in those cases... Dec 01 14:52:01 RP: Actually, here is probably a better solution: http://pastebin.com/GssdHtN5 Dec 01 15:08:32 Saur: you could use USRBINPATH Dec 01 15:09:02 RP: Didn't know that exists... Dec 01 15:27:03 <_qwerty_> Hi All I trying to create a bb file (http://pastebin.com/VKSd5bvG) to build custom kernel version but I get error about Missing SRC_URI checksum Dec 01 15:27:09 <_qwerty_> how I can fix it? Dec 01 15:28:11 _qwerty_: you need to use git://...protocol=https not https:// ... Dec 01 15:28:15 in SRC_URI Dec 01 15:28:34 git://...;protocol=https I meant Dec 01 15:28:45 RP: Would it be acceptable to add PACKAGECONFIG_append_class-native = " perl" to openssl.inc so that the perl scripts are installed when building openssl natively? Dec 01 15:29:21 _qwerty_: (or http, if you prefer) Dec 01 15:29:49 <_qwerty_> bluelightning: I changed but error still Dec 01 15:30:22 _qwerty_: same error or a different one? Dec 01 15:30:56 <_qwerty_> no different Dec 01 15:31:02 <_qwerty_> SRC_URI = "git://github.com/dwery/linux/tree/towertech-tt3201-can-cape;protocol=https;branch=${BRANCH} \ Dec 01 15:31:32 <_qwerty_> repository 'https://github.com/dwery/linux/tree/towertech-tt3201-can-cape/' not found Dec 01 15:32:54 _qwerty_: it looks like that is the wrong URL for the repository in any case Dec 01 15:33:24 _qwerty_: the correct one according to the link on the right would be https://github.com/dwery/beagleboard-linux.git Dec 01 15:33:55 _qwerty_: so to specify that in SRC_URI you would use SRC_URI = "git://github.com/dwery/beagleboard-linux.git;protocol=https;branch=${BRANCH} \ Dec 01 15:34:55 where BRANCH would have to be set to "towertech-tt3201-can-cape" Dec 01 15:40:45 <_qwerty_> bluelightning: thanks It is like your suggestion Dec 01 16:12:03 What is the distinction between inherited (bbclass) and required (includes)? Dec 01 16:12:34 Is there any reason I shouldn't use .bbclass for something that seems like it could also be an include? Dec 01 16:13:25 morning Dec 01 20:06:55 hi all Dec 01 20:07:22 i wanna use yocto to build an image for am3517 evm but dont know how to start Dec 01 20:07:38 where to download source code and how to build **** BEGIN LOGGING AT Mon Dec 01 21:20:39 2014 Dec 01 21:29:51 Quick DB interruption. Dec 01 21:38:40 hey Dec 01 21:38:56 who is around? **** ENDING LOGGING AT Tue Dec 02 02:59:58 2014