**** BEGIN LOGGING AT Fri Jun 17 02:59:58 2016 Jun 17 06:43:39 hi, I have deleted the deploy folder. How do I get it back? Jun 17 06:54:42 mwarning: I believe you have to call bitbake with the targets you need Jun 17 06:55:02 it should all be reused from sstate, so it will not take so long Jun 17 06:55:20 that won't help unless you wipe tmp, otherwise the stamps will let bitbake know the deploy tasks have already been run, so will be skipped Jun 17 06:55:31 either wipe tmp, or remove all the do_deploy stamps from tmp/stamps/ Jun 17 07:09:37 kergoth: where do I find that tmp folder? Jun 17 07:30:42 by default it's in the builddir Jun 17 07:53:54 bitbake.lock buildhistory cache conf sstate-cache tmp-glibc Jun 17 07:54:23 hm, I wonder which one fredcadete meant Jun 17 08:25:11 mwarning: sorry, dropped out Jun 17 08:25:19 np :) Jun 17 08:25:51 if it's not there, maybe your build has configured it to a different directory from the default Jun 17 08:26:04 try: bitbake -e | grep TMPDIR= Jun 17 08:26:27 TMPDIR="/yocto_ti/build/tmp-glibc" Jun 17 08:26:31 there you go Jun 17 08:26:34 ok Jun 17 08:27:32 fredcadete: well, but then everything needs to be compiled from ground up again. Jun 17 08:28:00 you mean if you delete it? Jun 17 08:28:13 yes Jun 17 08:28:22 it's 23GB in size on my system Jun 17 08:28:40 actually, for many end tasks yocto archives the results in the sstate-cache Jun 17 08:29:29 sstate-cache is 2GB Jun 17 08:29:36 so if you delete dir, then bitbake your image again, you will see many "SetScene" tasks instead of builds. this is bitbake taking archived results form sstate-cache Jun 17 08:29:57 I can rename it and see what happens Jun 17 08:30:13 yes, it's smaller because sstate-cache only keeps the output of the compile process, it does not have intermedia things like build directories and .o files Jun 17 08:30:40 do like this: mv tmp tmp-old Jun 17 08:30:48 then bitbake, see if it works Jun 17 08:31:00 if it does not, you still have your old state in tmp-old Jun 17 08:32:47 hello, can i use the preemp-rt patches with yocto for a raspberry pi image? Jun 17 08:39:30 fredcadete: looks like it has worked. the deploy folder is there again an looks fully populated. Jun 17 08:39:56 But it is funny that the old tmp-glibc was 23GB, but the new one is only .26GB Jun 17 08:40:00 2.6GB Jun 17 08:40:05 Hello Jun 17 08:40:16 hi Jun 17 08:42:12 mwarning: that's normal. If you go look in tmp-old/work/whatever-arch/whatever-recipe/ , you will see it has source files, build directory with .o files, an install directory, and package-split directories all taking up place Jun 17 08:42:43 compare with the same work directory for the new tmp dir, and it has almost nothing. Jun 17 08:42:59 hm, ok Jun 17 10:02:39 Can I do pip install in my bitbake recipes to build my python package dependencies? I couldn't find any custom recipe which uses requirements.txt Jun 17 10:21:03 rburton: hey, I looked for the pathes you talked about, but there are propably not yet in master, because runqemu still look for arg in given list. Could you tell me where I can find them ? Jun 17 10:22:06 mastier: they're on the oe-core list and not ready for merging yet. if you'd be interested in working on them then they'll appear with a search for runqemu rfc. Jun 17 10:33:59 rburton: you mean that patch ? http://patches.openembedded.org/patch/122065/ Jun 17 10:34:24 yes Jun 17 10:40:31 rburton: ok, great, last question, what would require to make this patch merged ? for the current master the patch does not apply Jun 17 10:40:52 off the top of my head i can't recall what the problem was Jun 17 10:41:02 obviously the first requirement is to be rebased :) Jun 17 10:50:04 rburton: I am quite new to this old-fashioned approach to pull requesting ;-) so if someone want badly to have his changes to be merged, must keep finger on the pulse Jun 17 10:50:31 ;) Jun 17 11:46:05 Can I do pip install in my bitbake recipes to build my python package dependencies? I couldn't find any custom recipe which uses requirements.txt Jun 17 12:17:26 hi, is it possible to use versions in dependencies of a recipes? Jun 17 12:21:05 mwarning: DEPENDS, no, RDEPENDS, yes Jun 17 12:23:11 rburton: I tried to add DEPENDS = "nano-2.2.5" to my recipe. It does not build, but meta-oe/recipes-support/nano/nano-2.2.5 exists/. Jun 17 12:23:34 you want just "nano" Jun 17 12:23:55 as that's like the name of the recipe, assuming its nano_2.2.5.bb Jun 17 12:25:25 yes, using just nano would work. But I like to say that I want a higher version than, let's say 2.2.0. Jun 17 12:25:46 or a specific version Jun 17 12:31:22 mwarning, you know about PREFERRED_VERSION? Jun 17 12:31:34 I know it isn't quite what you are trying to do Jun 17 12:31:53 Crofton|work: yes, but that only works in conf/local.conf Jun 17 12:32:07 or distro.conf Jun 17 12:32:13 distro.conf? Jun 17 12:32:49 never seen that, but it does not look like it is what I want. Jun 17 12:42:14 mwarning: you can't have versions in DEPENDS Jun 17 12:42:17 would be nice, i agree Jun 17 12:42:19 patches welcome Jun 17 12:42:34 even if it just results in the build aborting because you need to set preferred version Jun 17 12:42:46 yes Jun 17 12:44:48 basicly, I want to have my own release which contains a list of programs of a specific version. Jun 17 12:45:02 maybe someone can tell me how this can be achieved Jun 17 12:45:21 maybe my starting point is wrong Jun 17 12:47:13 mwarning, it sounds like you need a custom distro that sets PREFERRED_VERSIONS Jun 17 12:47:52 looks like it Jun 17 12:55:20 hey, im maintaing an old application running with xulrunner. The application worked fine in jethro but when i migrated to krogoth it wont load. accordning to ldd no libraries are missing. The output of the jsconsole in xulrruner says "The character encoding of the plain text document was not declared". Iave checked all the meta tags an charset is set to utf-8 on all but one where an ISO charset is set. What package could i be missing ? Jun 17 12:55:44 should bitbake catch all gplv3 packages during the initial parse if set as incompatible, or can it fail later on? Jun 17 13:08:31 CTtpollard: should fail at parse time Jun 17 13:08:50 rburton: noted Jun 17 13:09:15 rburton: are any packages exceptions to this? Jun 17 13:12:37 is there a way to let do_install() do nothing (it is a dummy recipe) - I get an error that the package cannot be installed. Jun 17 13:17:09 seebs: around? Jun 17 13:19:15 mwarning: I'm not sure, maybe this helps? http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#var-ALLOW_EMPTY Jun 17 13:23:52 he won't likely be around for another couple hours Jun 17 13:31:23 fredcadete: that worked! :-) Jun 17 13:31:54 mwarning: great! Jun 17 14:27:35 * kergoth yawns Jun 17 15:42:50 beth left intel? huh Jun 17 15:47:31 kergoth: yup. She got an offer she couldn't refuse. Formed her own company to consult for someone in Netherlands, but can work remote from home most of the time. Jun 17 15:47:54 nice, sounds like a good opportunity Jun 17 15:48:21 I think so. Jun 17 15:49:32 Left most of the AB stuff to me. She's still around and involved, though, and will be the gatekeeper for the AB git repo as far as applying patches, etc. Jun 17 15:53:35 ah, cool. sounds like that should help ease the transition Jun 17 16:02:16 RP: around-ish. Might be sick, though, so possibly not smart. Jun 17 16:03:28 seebs: sorry to hear that. It was just to give you a heads up on https://bugzilla.yoctoproject.org/show_bug.cgi?id=9761 Jun 17 16:03:29 Bug 9761: normal, Medium+, 2.2 M1, eduard.bartosh, IN PROGRESS REVIEW , Failed to extract rootfs by using runqemu-extract-sdk Jun 17 16:03:51 seebs: we think we understand the problem and its not strictly pseudo but its messy :( Jun 17 16:08:39 does anyone install a toolchain on their target ARM device to develop on target? Jun 17 16:11:16 I have, but I don't do it a lot for actual development, more quick prototyping and debugging Jun 17 16:14:09 that makes sense Jun 17 16:15:29 ... You know, the ldflags thing seemed like it should be reasonable, but that may be a reason to undo that. Jun 17 16:16:13 and the chrpath thing seems reasonable. Jun 17 16:17:57 pseudo needs to work with the system and "native" versions of libc.so... the rpath only points to the 'native' version Jun 17 16:18:13 so you end up running a system binary with an rpath that tries to load an incompatible "native" version, and it died Jun 17 16:18:28 get the rpath out of there, and let the executables handle the rpath issues and it all works Jun 17 16:18:42 (RP correct me if I'm wrong) Jun 17 16:26:05 hi there, I'm trying to clone repository from android.intel.com that starts with 'ssh://'. Yocto fetcher seems not to understand that protocol. How do I make it work? Jun 17 16:27:00 fray: correct, we need to let the selected libdl.so search the right system paths. If there is an RPATH it all gets messy Jun 17 16:27:19 The RPATH may be right for SDK components but not native ones Jun 17 16:28:06 kergoth: the above is from your pseudo LDFLAGS change :( Jun 17 16:28:54 * RP suspects we should rip a load of the rpath stuff out of the SDK LDFLAGS now Jun 17 16:29:25 Xz: the URL should be something like "git://user@host/path;protocol=ssh" Jun 17 16:31:12 incidentally, I'm not finding the doc for this... Jun 17 16:40:03 fredcadete: that worked! magic Jun 17 16:41:08 Xz: what a wonderful thing to happen on a friday afternoon Jun 17 16:41:17 have a nice weekend Jun 17 16:42:00 !thanks Jun 17 16:42:08 -.-V Jun 17 16:47:23 can I skip 'do_patch' step for kernel build? Jun 17 16:50:02 RP: yeah, I saw, that sucks, sorry. i'd expect either everything in the sdk to be using that libc or none, not some combination of the two :\ Jun 17 17:10:36 kernel build seems very difficult nowadays Jun 17 17:11:13 I have custom repo with custom kernel that I want to add to my image. When removing 'do_patch' step it fails saying 'could not sanitize configuration fragments'. Jun 17 17:13:29 if I preserve do_patch then it tries to apply some ARM patch that won't apply - and I'm trying to build x64 arch Jun 17 17:20:09 http://pastebin.com/EGLEGapE Jun 17 17:20:20 I don't know why it tries to apply some random patches Jun 17 17:22:58 I am not a kernel expert.. but to start with.. the system isn't apply random patches.. Jun 17 17:23:27 In the yocto project kernel source, there is a defined set of patches and features that is combined to produce the final source code that is used to compile.. Jun 17 17:23:41 fray: I would love just to pull my custom kernel Jun 17 17:23:42 if you change the sources, feature or configuration that the overall patch set may change.. Jun 17 17:23:55 fray: it's already patched Jun 17 17:23:55 then don't use linux-yocto Jun 17 17:24:06 fray: how do I add my kernel to yocto build then? Jun 17 17:24:32 create a new recipe for your kernel Jun 17 17:25:14 there were docs on doing this last time i looked.. on what you needed to inherit (class wise) and some other specifics.. Jun 17 17:25:22 then use your version instead of linux-yocto Jun 17 17:25:37 at a minimum you will need inherit kernel Jun 17 17:26:02 specify your src-Uri and defconfig... for some reason I think ther ewas a linux-yocto-custom or something like that.. Jun 17 17:26:13 there was an example on using a kernel.org kernel directly Jun 17 17:26:30 fray: was it in docs on yoctoproject.org? Jun 17 17:26:54 I don't remember, but I believe it should be in the kernel section Jun 17 17:27:13 look in the poky checkout 'meta-skeleton' for recipes-kernel/linux/linux-yocto-custom.bb that might be what you want Jun 17 17:34:00 does anyone know how to get the lcd3 cape working on the beaglebone black?, it seems to me that linux-yocto (which is what MACHINE=beaglebone sues) does not contain the driver for it, I tried using linux-ti-staging from meta-ti and it didnt work either Jun 17 17:34:46 fray: let's say I finished my linux-yocto-custom recipe Jun 17 17:34:52 Xz: yes, there's coverage of custom kernel builds on the yoctoproject.org docs Jun 17 17:34:55 fray: how do I replace standard kernel with my custom one? Jun 17 17:35:13 kergoth: found the manual already, it explains how to create the recipe Jun 17 17:35:16 PREFERRED_PROVIDER_virtual/kernel = "your-recipe-name" Jun 17 17:35:26 kergoth: in local.conf? Jun 17 17:35:29 though with correct use of COMPATIBLE_MACHINE, explicit pref is often unneeded Jun 17 17:35:40 wherever you want to put it, bitbake doesn't give a crap as long as it's set and is in the global config metadata Jun 17 17:35:56 kergoth: let me try that Jun 17 17:35:59 normally the machine would do it, but you're overriding what the bsp is doing, so yes, local.conf would be appropriate if you don't want to create your own machine (which, to be clear, would be the better route) Jun 17 17:36:36 kergoth: I'm just testing couple of kernel patches Jun 17 17:36:43 kergoth: that will eventually be upstreamed Jun 17 17:36:53 kergoth: so no need for spinning new layer with all its configuration files Jun 17 17:37:04 kergoth: I pretty much need to do an engineering build, make sure everything works Jun 17 17:37:28 kergoth: after that I will work on getting it integraded into yocto upstreamed kernel Jun 17 17:38:01 if it's desitned for upstream, why not just modify the kernel rather than replacing it with your own? or at least use the existing one as a baseline, copy it, rather than going the custom route? Jun 17 17:38:13 if upstream is a linux-yocto kernel, then you should use the linux-yocto tooling to submit your patches to the source Jun 17 17:39:09 kergoth: the story is - kernel work was done by Yocto-ignorant kernel dev Jun 17 17:39:21 kergoth: I'm Yocto, kernel-ignorant guy Jun 17 17:39:27 kergoth: we just try to make it work together :) Jun 17 17:40:31 kergoth: so he ported plenty of patches on top of the tree that was building fine using linux-yocto bbappend Jun 17 17:40:59 kergoth: now it doesn't build anymore - do_patch step fails applying some ARM patches Jun 17 17:41:26 kergoth: which is weird, as my arch ix x64. but I guess these days kernel build got way more complicated Jun 17 17:41:31 heh Jun 17 17:41:37 not really Jun 17 17:42:10 make a small error in any part of the system, and it goes off the rails. Jun 17 17:42:18 simply not understanding it, doesn’t make it “way harder" Jun 17 17:43:18 zeddii_home: there is no point in me and you arguing about how kernel build changed over time Jun 17 17:43:30 heh Jun 17 17:43:35 * zeddii_home is more than aware Jun 17 17:43:43 zeddii_home: my expectation is that if I build x64 kernel then I'm dealing with x64 problems, not ARM related ones Jun 17 17:43:51 because you hosed the recipe Jun 17 17:43:54 don’t know what to tell you Jun 17 17:44:00 when you use a recipe, that has patches Jun 17 17:44:05 and point it at a different tree Jun 17 17:44:10 it is still going to try and apply its patches Jun 17 17:44:24 that’s no different than any recipe in the system. Jun 17 17:44:52 zeddii_home: well, default URI is to get kernel from yoctoproject.org Jun 17 17:45:11 zeddii_home: that's something that 'WE' host, so why having additional patches in the layer for it??? Jun 17 17:45:24 -ENOPARSE Jun 17 17:45:43 you are either using the YP kernel or you are not.. if you have made changes, you are not.. Jun 17 17:46:50 did you post your kernel recipe ? I just re-joined the channel and didn’t see it. Jun 17 17:48:08 zeddii_home: http://pastebin.com/dGUj5HDX Jun 17 17:48:11 not much in there Jun 17 17:48:18 that's my bbappend Jun 17 17:48:52 it goes along with couple of config fragments Jun 17 17:48:54 that’s going to try and build the BSP that is defined in the yocto-kernel-cache, against a tree that doesn’t have the patches defined in the yocto kernel cache Jun 17 17:48:55 no patches in my layer Jun 17 17:49:07 so the tools are going to try and make the tree match the patches that the kernel-cache is specifying. Jun 17 17:49:23 so you either need your own machine, or just drop the kernel cache and provide a defconfig Jun 17 17:50:05 zeddii_home: isn't defconfig equal to config fragments? Jun 17 17:50:12 nope. Jun 17 17:50:31 it just gets block applied, and you get what you get. defconfig is part of the core kernel.bbclass. Jun 17 17:50:47 zeddii_home: so I just cat all config fragments into 1 file and that will be defconfig, right? Jun 17 17:51:15 maybe. better to just do a configure run outside of the build system Jun 17 17:51:23 and save the .config as ‘defconfig’ and then feed it back in. Jun 17 17:51:38 the defconfig will have more values filled in, than the concatenated fragments. Jun 17 17:51:43 the kernel-cache has instructions for each machine on what features to enable (read that as what patches to apply and kernel options to enable).. you have a custom kernel that does not have the patches available.. so the mismatch is telling the system to reconstruct the kernel and now your patches don't apply because of this.. they both have to be in sync Jun 17 17:52:06 fray: what is kernel-cache? Jun 17 17:52:13 SRC_URI = "git://android.intel.com:29418/a/bsp/kernel/bxt;protocol=ssh;name=machine;branch=${KBRANCH}; \ Jun 17 17:52:13 git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.4;destsuffix=${KMETA}" Jun 17 17:52:18 second entry of your SRC_URI Jun 17 17:53:01 that’s the kernel meta-data, it’s in the docs. Jun 17 17:53:16 what would be the forkflow to make it work with existing SRC_URI as is? Jun 17 17:53:23 the name is historically significant, but easier to just call it the meta data when describing it. Jun 17 17:53:41 Xz: if you aren’t changing the source tree ? Jun 17 17:53:49 just add your patches on the end of the src_uri like any recipe Jun 17 17:54:12 zeddii_home: build will brake the same way Jun 17 17:54:17 if you do need to change the source tree, the linux-yocto-custom, or the kernel recipes you can find in the meta-* layers of the oe ecosystem will do. Jun 17 17:54:21 Xz: nope. Jun 17 17:54:29 zeddii_home: apparently there are some conflicts between my patches and kernel-cache patches Jun 17 17:55:08 folks are building like that all day, every day. unless something has broken in the past couple of days, and no one has raised a bug and screamed at me. Jun 17 17:55:44 if you can point me at your patches. I can bbappend them to my linux-yocto-4.4 and see what happens. Jun 17 17:55:44 zeddii_home: what's the difference between applying patches using patch files inside the layer vs having them applied right away in git-clone ? Jun 17 17:56:21 I’m not sure I follow. Jun 17 17:56:55 if you are using the kern-tools (as linux-yocto does). they make sure you are building the tree that it expects. the patches are integrated already into linux-yocto, so they are skipped. Jun 17 17:57:08 but if you point at another tree, they aren’t applied, and it knows that. so it tries to apply them. Jun 17 17:57:19 but like any patch, if that tree has a different context, it goes boom. Jun 17 17:57:30 what is kern-tools? Jun 17 17:57:44 as I said - the dev that prepared the tree has no idea about Yocto Jun 17 17:57:58 so he just backported set of patches on top of the tree that *used to build with my bbappend* Jun 17 17:58:23 do you have that bbappend ? because what you have in yours, is doing what I’d expect. Jun 17 17:58:50 zeddii_home: I do, let me dig it Jun 17 18:00:00 zeddii_home: http://pastebin.com/F0MkmQUQ Jun 17 18:00:07 zeddii_home: that's what I used to have - and it built fine Jun 17 18:00:12 yah Jun 17 18:00:17 and that tree is a linux-yocto tree Jun 17 18:00:24 * zeddii_home has built steve’s tree before Jun 17 18:00:38 zeddii_home: what dev did - he took the tree, applied couple of patches and now it doesn't build anymore Jun 17 18:00:51 zeddii_home: I pretty much just pointed recipe to his tree and changed branch name Jun 17 18:00:54 you are pointing at a different kernel tree. Jun 17 18:01:06 zeddii_home: yeah, but it's the same baseline + some patches Jun 17 18:01:16 doesn’t matter. Jun 17 18:01:17 git://sandbox.sakoman.com/linux-yocto-4.4.git Jun 17 18:01:24 has all my integrated patches that are part of linux-yocto Jun 17 18:01:26 and the tools know that. Jun 17 18:01:35 you pointed the same build process at a different tree. Jun 17 18:01:45 so it is trying to apply patches to make it consistent. Jun 17 18:01:51 and they won’t apply to that baseline. Jun 17 18:01:55 zeddii_home: I don't follow Jun 17 18:02:06 zeddii_home: are you saying if I forked sakoman.com onto android.intel.com Jun 17 18:02:12 the kernel-cache, in your src_uri Jun 17 18:02:14 zeddii_home: and didn't apply any patches - yocto would behave differently? Jun 17 18:02:16 *has* patches Jun 17 18:02:30 if you had all the branches the same, yes, it should work fine. Jun 17 18:02:37 but if you want to use your own tree, do that. Jun 17 18:02:54 just don’t use the kernel-cache, and don’t inherit linux-yocto. Jun 17 18:03:13 zeddii_home: well, eventually all these patches will be integrated into sakoman.com Jun 17 18:03:19 zeddii_home: I just need engineering builds to test it Jun 17 18:03:29 zeddii_home: later on, sakoman.com patches will go upstreamed into yoctoproject.org Jun 17 18:04:32 zeddii_home: in other words, android.intel.com contains sakoman.com + couple of patches Jun 17 18:04:51 zeddii_home: for me it's no difference if the diff is applied straight into git tree, or using SRC_URI += "file://..." Jun 17 18:05:07 zeddii_home: because at the end of the day workdir will be the same Jun 17 18:05:11 yah. exactly. Jun 17 18:05:17 like I said, if you want me to try a build. Jun 17 18:05:28 if I can see the patches, I can always try a build and see if something broke. Jun 17 18:05:33 it happens ;) Jun 17 19:18:42 hi everybody, I created an image and set IMAGE_FSTYPES = "hddimg", then now when I boot on a pendrive with the image installed it prompts to me boot or install Jun 17 19:19:32 how can I disable it to just boot on my image instead syslinux Jun 17 19:19:34 ? Jun 17 19:21:59 I saw on image.bbclass if IMAGE_FSTYPE contains iso or hddimg it inherits image-live class Jun 17 19:22:20 and this class sets the prompts boot and install Jun 17 19:22:52 but I don't want it and I did not find out how to disable Jun 17 19:23:13 yeah, there's a bunch of hardcoded live-oriented stuff in live/hddimg/iso construction, sadly Jun 17 19:23:46 there is a user friendly way to make a hddimg without this live boot? Jun 17 19:25:25 I want the initramfs to boot the image, but I don't want this syslinux prompt etc.. Jun 17 19:28:41 I think I found what I must do Jun 17 19:29:11 the vmdk class inherit the boot-directdisk class, that I think is what I want Jun 17 19:29:44 thanks Jun 17 19:38:46 might also want to switch the initramfs. by default it's using one that includes the installer stuff Jun 17 19:38:54 at least hddimg/live is, dunno about vmdk Jun 17 20:13:07 Anyone had to deal with trying to patch a file which is in dos line ending format? including those in the patch, as generated by diff, breaks patch application, and removing them breaks as it says the line endings don't match up (no crap). worst case could add a do_unpack postfunc to frodos the things Jun 17 20:37:28 okay, that's the last of my ldflags fixes submitted after doing a massive world build with the poisoning patch enabled just for cross. think i should be ready to re-submit in the near future for m2 if appropriate Jun 17 21:36:40 Hmm Jun 18 01:17:10 exit Jun 18 01:17:13 ups Jun 18 01:17:19 not here I guess Jun 18 02:43:58 It seems libwebsockets.org is down so bitbake edison-image fails when trying to download http://git.libwebsockets.org/cgi-bin/cgit/libwebsockets/snapshot/libwebsockets-1.23-chrome32-firefox24.tar.gz but I'd like to build only the kernel. I'm aiming to write a kernel module. Is there a way to avoid the problem target? **** ENDING LOGGING AT Sat Jun 18 02:59:58 2016