**** BEGIN LOGGING AT Wed Jun 03 02:59:59 2015 Jun 03 04:46:20 <[w00t]> Hi, I'm crafting a recipe for a project depending on protobuf.. As I'm building the project it complains that it does not include the header files. From what I can see the header files are present in the -dev rpm package, how do I make them available in my project upon building it? Jun 03 04:46:59 <[w00t]> I've added protobuf to the DEPEND parameter Jun 03 04:48:39 [w00t], have you tried changing the dependency to protobuf-dev? Jun 03 04:49:16 not sure if you need both protobuf and protobuf-dev Jun 03 04:50:17 <[w00t]> redengin: Yes, it complains that nothing provides protobuf-dev Jun 03 04:51:27 <[w00t]> redengin: when using both protobuf and protobuf-dev as well as only protobuf-dev Jun 03 04:51:55 which protobuf recipe are you using? Jun 03 04:52:28 <[w00t]> 2.5.0 from meta-virtualization/recipes-container/criu Jun 03 04:54:02 <[w00t]> Could I potentially add the include files in an bbappend file? Jun 03 04:55:39 [w00t], it looks like that recipe is hacking on the pkg-config files to try and add the headers and libraries Jun 03 04:57:17 sorry, but I'm kinda busy right now to turn my attention to debugging it. It doesn't expose a protobuf-dev so that is out Jun 03 04:58:58 <[w00t]> redengin: Ok, thanks Jun 03 05:01:10 [w00t], my suggestion would be to edit the recipe and drop all the pkg-config hackery, and do the necessary copies in the do_install Jun 03 05:03:01 <[w00t]> redengin: Ok, it seems like the hackery is only related to the ptest though Jun 03 05:03:28 <[w00t]> redengin: I'll try to fix it.. Jun 03 05:03:56 [w00t], ah, true Jun 03 06:33:25 Good morning folks. Jun 03 06:35:30 Is there a methodology to have a repository created by yocto builds? Perferably i want to manage a standard debian repository. Jun 03 06:36:32 irontia, what do you mean? as in you want to store all the generated rpms separate from the image? Jun 03 06:50:22 irontia: it's possible to create a package feed out of an openembedded build, but my google-fu is too weak at the moment to find proper instructions. maybe look at what the angstrom project does, as they basically do exactly that. Jun 03 07:01:50 good morning Jun 03 07:01:50 thanks LetoThe2nd Jun 03 07:03:11 redengin: I want to build an distribution. From my past experiences that means to have a webserver providing a package repository so the targets can install packages and update... Jun 03 07:04:43 I want to be able to add and update packages to that repository also from the build system. And it should not always build everything. Packages that didn't change should not be rebuild. I don't feel i have the full yocto-understanding to fullfill this. I will look at package feeds first. Jun 03 07:04:45 irontia, the only way I know of is to create an image based on a distro that uses all the recipes and then you'd have a set of rpm's that you could host Jun 03 07:05:47 irontia: to go nitpicking, you don't want to create a distribution (that is what poky, respectively its distro.conf does). you probably want to create a package repository, preferrable reachably through some webservice, for the distribution that you already have/are creating anyways. Jun 03 07:06:40 irontia: so your buzzwords are not "distribution" or such, but rather "package repository" or "package feed" Jun 03 07:07:37 Right, i would fork poky or parts of it as a basis for distribution. And part of that is a need for package management / package repository management. Jun 03 07:09:21 irontia: you're still mixing it up a bit. you can instantly get package management in a poky build by IMAGE_FEATURES += "package_management" Jun 03 07:09:27 irontia, I think LetoThe2nd is referring to how distro is used inside yocto/bitbake, its more of a customization level to put things together, rather than a giant library Jun 03 07:09:55 I guess i found someone describing my needs: http://www.jumpnowtek.com/yocto/Using-your-build-workstation-as-a-remote-package-repository.html Jun 03 07:10:15 irontia: so you're really looking just for a way to crate a proper download feed. the "distribution" and "package management" part are all already finished Jun 03 07:11:29 redengin: people just seem to be constantly confusing "distribution" and "package repository server somewhere on the web" Jun 03 07:12:23 LetoThe2nd, it kinda makes sense, it'd be a cool feature if you could build a package repository to support an image Jun 03 07:12:24 redengin: because the latter is just a means of comfortably handing out the former, but its *not* part of it or necessary Jun 03 07:12:57 we've had proper distributions with package managers and all that on floppies and cdrom for years. Jun 03 07:13:15 so clearly some online means cannot be an integral part of the term "distribution" Jun 03 07:14:25 LetoThe2nd, I'm not disagreeing, I'm just thinking a bitbake "repository.recipe" would be a cool feature (i.e. generate a full set of packages not specific to an image) Jun 03 07:15:26 redengin: and yes, of course its useful, "cool" and certainly possible to have an online paackage repository to support an OE created image. but to get there, its first crucial to get the terminology sorted out, because otherwise everybody just says "distribution". Jun 03 07:15:27 but it'd still have all the distro/machine/etc customizations specific for an image Jun 03 07:16:37 redengin: and its been done before, i repeat: just look at what the angstrom project does. its opkg and not rpm as irontia asked for, but basically its exactly that. an OE build that feeds an online package repository. Jun 03 07:18:54 LetoThe2nd, sorry, I missed the part about the angstrom project Jun 03 07:19:34 redengin: np, thats why i repeated it :) Jun 03 07:27:04 morning all Jun 03 07:27:50 * LetoThe2nd mourns all, too. Jun 03 07:28:04 but hey, long weekend ahead! Jun 03 07:38:11 roric: morning Jun 03 08:32:01 <[w00t]> Is there someplace where the bitbake build process is clearly specified..? In particular I'm interested in how dependencies are pulled in when building a package Jun 03 08:33:38 [w00t]: do you mean build-time dependencies or runtime dependencies? Jun 03 08:36:17 <[w00t]> bluelightning: build-time Jun 03 08:38:20 I don't know that we have documentation that covers this specifically (or at least I can't immediately find it) Jun 03 08:39:19 ultimately bitbake deals with almost everything it needs to actually carry out in the form of tasks, and thus dependencies end up being dependencies between tasks Jun 03 08:40:06 <[w00t]> bluelightning: ok, thanks Jun 03 08:40:22 if recipe 'a' has DEPENDS = "b" that translates to recipe a's do_configure task depending on recipe b's do_populate_sysroot task Jun 03 08:41:17 there are other subtleties (and a few explicit task dependencies declared within the metadata) but DEPENDS is how most of the dependencies are expressed Jun 03 08:44:13 bluelightning, I think its best to go off the most recent docs, since the legacy code has a lot of alternative ways to get it done Jun 03 08:44:49 hi, i'm thikning of trying buildbot for build/release management stuff. since yocto uses it, i thought if someone could share their expereince using it. Jun 03 08:45:28 i'm newbie to build bot, so wanted to know if its not too big to setup or try. Jun 03 08:45:54 hitlin37, what are you trying to do? Jun 03 08:46:30 we have some private project that has different parts that needs to be build. Jun 03 08:46:41 suhc as OS and other software components Jun 03 08:46:52 redengin: sure, I'm simplifying... I can go into more details in response to specific questions ;) Jun 03 08:46:56 so, sommething that could make the job easier to make a release Jun 03 08:47:07 releases. Jun 03 08:47:50 hitlin37: can't share too much, just: we use jenkins, and it works(TM) Jun 03 08:47:53 and easier to share the releases method with other developers in the team, so that anyone could commit and make a release Jun 03 08:48:07 ah, thanks LetoThe2nd Jun 03 08:48:20 i have heard jetkins, it looks good Jun 03 08:48:43 hitlin37: in the end, its just a git repo watcher and trigger that runs our project specific build scripts Jun 03 08:48:50 (at least for us) Jun 03 08:49:01 right now, i run these scripts manually :) Jun 03 08:49:08 but its good to have some systems Jun 03 08:49:09 then stores some 'artifacts' away, and starts over Jun 03 08:49:12 hitlin37, what kind of scripts? Jun 03 08:49:23 so that other people can do it in easier way. Jun 03 08:49:50 redengin: its like build script that do bunch of stuff and creates an os image Jun 03 08:50:14 reminds me, our new build server should arrive very soon ;) Jun 03 08:50:22 hitlin37, I've done a lot of build management, usually when ppl say scripts, the build system is full of incongruent variations Jun 03 08:50:33 or packages software from bunch of libraries Jun 03 08:51:03 redengin: yes, you are very true Jun 03 08:51:14 the script will fail on other people machine Jun 03 08:51:30 my advice is to map out what you want the ideal build for everything to do, and then figure out how to incrementally refactor the current stuff Jun 03 08:51:32 redengin: depends, it can also mean: there is aproper automation script that just needs the target and credentials Jun 03 08:51:37 that's why i need a build management on some server Jun 03 08:51:41 a build engine isn't going to magically do it Jun 03 08:51:54 hmm Jun 03 08:52:04 redengin: ++ Jun 03 08:52:34 first step is always, make your build reproductible, take out magic that you need to do manually or that works only on your box Jun 03 08:53:03 after that, you can add some automation to trigger that and take the outcome Jun 03 08:53:29 I'd even posit that you should be able to build your build system from a script, then you know it's consistent Jun 03 08:54:16 redengin: you could even add a script that creates a script to script the creation of your build script! Jun 03 08:56:13 what we have right now here needs only python and the prerequisites stated in the yocto quick start. then everything from checking out, through getting the right commits/branch and setting conf/*.conf etc is fully automated Jun 03 08:56:14 LetoThe2nd, I believe the singularity lies in creating the build system, so all attempts to go further backwards lead to the big bang Jun 03 08:56:38 redengin: i like big bangs! corben dallas to the rescue! Jun 03 10:18:27 thanks LetoThe2nd and redengin . i like the part "figure out how to incrementally refactor the current stuff" Jun 03 10:50:49 anyone can explain how I get to have the x86_64-arago-linux-g++ compiler understand the -fuse-ld=gold command? Jun 03 12:17:01 uhhmm.. so.. i'm once again trying to install a custom kernel config for raspberrypi... Jun 03 12:17:43 i struggled with this some year or so ago, found out there was no fragment support, etc... https://lists.yoctoproject.org/pipermail/yocto/2014-June/020172.html Jun 03 12:18:18 i finally got it working with this method: https://lists.yoctoproject.org/pipermail/yocto/2014-June/020174.html Jun 03 12:18:51 but now when i've returned to this project, new kernel has arrived and i can't get it to work anymore :( Jun 03 12:19:05 anyone familiar with meta-raspberrypi who could give me some hints? Jun 03 13:22:33 ionte: what's wrong into following again the same steps? Jun 03 13:23:52 mckoan: it did not work for some reason, not sure why. i finally got it working though... Jun 03 13:57:55 erbo, go eftermiddag =) Jun 03 15:11:04 HI team , yesterday I did the final experiments with MPI + Yocto . And it works like a charm :) . If you have any specific feedback please do not hesitate to tell me . The next phase is to test it with some real HW ( minnowboards ) and publish the results. The real goal is to modify MPI to make it lighter and faster for embedded and IoT. Jun 03 15:11:40 in the end I will try to look for a way to merge it into the Open Interconnect standard Jun 03 15:11:49 open for comments :) Jun 03 16:18:09 Hi, I want to extend a defconfig file defined in a layer. The configurations I want to change are already present in the defconfig file. I created a .cfg file in my layer, added it in my bbappend of the kernel recipe, however the changes are never included in the final defconfig Jun 03 16:18:40 If I make the changes in the defconfig directly, those changes are applied, but that breaks the entire point of not changing a layer that isn't "mine" Jun 03 16:18:52 Why is this happening? Any ideas? Any ideas of how to solve this as well? Jun 03 16:20:23 cfg files only work for kernel recipes that inherit kernel-yocto Jun 03 16:20:45 joshuagl in my case I'm adding them in a .bbappend of the kernel recipe Jun 03 16:20:51 So it should work, shouldn't it? Jun 03 16:21:25 Ah, just found that in the recipe it inherits "kernel" only Jun 03 16:21:31 Not "kernel-yocto" Jun 03 16:21:41 How should I proceed in this case? Jun 03 16:23:04 probably the easiest thing to do is cp the defconfig into your layer and make the modifications you require Jun 03 16:24:07 And prepend the FILESEXTRAPATHS variable to "force" bitbake to find my defconfig before the original? Jun 03 16:24:21 Would that work, considering this is an append of the original recipe? Jun 03 16:24:47 yes, I'm pretty sure that works Jun 03 16:24:54 * joshuagl vaguely recalls doing the same Jun 03 16:25:11 Right. I'm gonna try that joshuagl and will report back in some minutes. Thanks :) Jun 03 16:37:46 joshuagl: things didn't work very well. bitbake is still using the "old" defconfig file Jun 03 16:39:34 Is it a thing of appending or prepending my path? I'm prepending right now, but I'm not sure if bitbake searches forward or backward in the paths provided Jun 03 16:41:40 DS__: I'd expect a prepend to work, do you know what tasks were run? do you need to cleansstate? Jun 03 16:42:22 joshuagl: I'm running a "bitbake -c clean", which in my experience forces the entire rebuild of that recipe Jun 03 16:42:43 in my experience as in: I see the configure, compile etc. tasks running again Jun 03 16:42:56 ah, OK - hmm Jun 03 16:43:32 OK, my bbappend that overrides the defconfig looks like: Jun 03 16:43:33 FILESEXTRAPATHS_prepend := "${THISDIR}/files:" Jun 03 16:43:34 SRC_URI += "file://defconfig" Jun 03 16:44:24 http://pastebin.com/ES3gknaz Jun 03 16:44:28 Exactly Jun 03 16:44:35 That's what my bbappend does Jun 03 16:45:30 hmm, all I can tell you is that the lines I pasted WFM Jun 03 16:47:56 joshuagl: which version of yocto are you using? Jun 03 16:48:39 fido 1.8 Jun 03 16:48:50 Same as me. This is weird :( Jun 03 16:49:35 Well, I'll try some more things. If I find anything that works I'll let you know. Thank you for your help! Jun 03 16:50:21 you could cleansstate or even cleanall to make sure you're starting from a clean slate, I'd imagine adding an append invalidates the cache but I don't know that for certain Jun 03 16:50:48 then pass some -V's to increase the verbosity and see whether the file is being used Jun 03 16:51:36 when I say -V's I mean -D's i.e bitbake virtual/kernel -c cleansstate && bitbake virtual/kernel -DDD Jun 03 16:51:55 * joshuagl heads off Jun 03 16:55:40 joshuagl: yeah, I'm gonna try that. Thanks for the tip Jun 03 17:11:57 joshuagl: you're awesome! :) Jun 03 17:12:42 joshuagl: thing is: bitbake was searching for / first, before searching only in , and it didn't come to me that in the other layer the defconfig file was inside a folder Jun 03 17:13:04 I updated my files directory to have this directory and things worked :) Jun 03 17:13:15 That -DDD trick was awesome. I didn't know it. Thank you for your help! Jun 03 19:11:41 Before I bang my head against it again, is jdk 1.8 still only supported on aarch64? Jun 03 20:06:10 Hi! I've created a python recipe that uses cffi. I need to compile something locally and output that in the site-packages directory. To do that in my machine, I just have to set an option in the setup.py, and cffi's integration will do the job for me. However, it appears that bitbake uses a different python than my machine's, and because it doesn't have cffi, the file never gets compiled as a result. How do I make yocto have cffi as a mod Jun 03 20:06:43 add it to python-native Jun 03 20:07:05 RP: do we have latest build runs with gcc-5 somewhere ? Jun 03 20:07:21 RP: I am interested to see x86_64 builds after binutils fixes Jun 03 20:07:42 onoffon: what do you mean? I've googled a bit and found this python-native thing, but didn't understand it very well. Does that mean I have to turn python-cffi into a native package? Jun 03 20:07:57 yes Jun 03 20:08:02 as well Jun 03 20:08:14 And then specify nativesdk-python-cffi in the TOOLCHAIN_HOST_TASK? Jun 03 20:08:44 OE's dependency on python meant that we ended up building our own and not rely on the one from build host Jun 03 20:09:02 if you want that it should go into SDK then yes Jun 03 20:10:02 I just want bitbake's python (whatever that is) to have cffi as a module Jun 03 20:10:21 That way the option I've set in setup.py will work Jun 03 20:13:53 OK then you just need native version Jun 03 20:13:59 not sdk one Jun 03 20:14:18 khem`: so I inherit "native" instead of "nativesdk"? Jun 03 20:15:17 yes Jun 03 20:15:57 What should be the name I put in TOOLCHAIN_HOST_TASK? Jun 03 20:16:13 I've tried 'native-python-cffi' but bitbake didn't pick it up Jun 03 20:18:22 you dont have to Jun 03 20:18:39 just add the proper dependency on the recipe needing it Jun 03 20:19:06 Bitbake will automatically parse the recipe and know it is a native recipe, and then automatically build it? Jun 03 20:20:02 I just tried baking stuff, but it doesn't seem the native recipes got picked up Jun 03 20:22:16 yes Jun 03 20:22:32 add a dependency on native- Jun 03 20:22:39 or -native Jun 03 20:24:10 Ah! Gotcha Jun 03 20:24:45 I did that and got this feedback from bitbake: "WARNING: QA Issue: python-tss rdepends on python-cffi-native, but it isn't a build dependency? [build-deps]" Jun 03 20:25:13 And then the build failed because when trying to install python-tss, it said no package provided python-cffi-native Jun 03 20:25:39 That recipe was just created exactly for that to work :( Jun 03 20:26:11 Duh, maybe it should've been "depends" instead of "rdepends" Jun 03 20:26:40 Of course it wouldn't work with rdepends :) Jun 03 20:28:05 khem`: this doesn't appear to have worked. Bitbake's python still didn't recognize the option in setup.py Jun 03 20:29:06 "/home/...../tmp/sysroots/x86_64-linux/usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: 'cffi_modules'" Jun 03 20:29:44 DEPENDS += "python-cffi-native" Jun 03 20:29:54 Yup, I did that Jun 03 20:30:04 ok and you wrote recipe to provide it ? Jun 03 20:30:22 if not you will need that Jun 03 20:32:11 Yes Jun 03 20:32:41 Basically I copied the recipe from meta-opembedded and added an "inherit native" as the last clause Jun 03 20:33:16 No errors with the baking happened, but from the log of python-tss, I get this warning, which shows that bitbake's python didn't get the module Jun 03 20:37:28 Damn this is beautiful. native recipes to build the stuff you need to build the image. Now I only gotta make it work haha Jun 03 20:39:21 khem`: ok. I have confirmed that python-cffi-native is being built. It's inside the site-packages directory of the native python Jun 03 20:39:33 For some reason it's not integrating with the native distutils Jun 03 20:39:40 I'll figure this out now Jun 03 20:39:43 Thanks for your help Jun 03 20:50:06 Ok khem` ! Got it working :) Thanks for all your help Jun 03 21:22:34 Does 1.9 have a codename? (wiki sez no, but I don't believe that. https://wiki.yoctoproject.org/wiki/Releases ) Jun 03 21:44:56 khem`: no, I should queue one up Jun 03 21:45:07 gabrbedd: not yet, no Jun 03 21:45:18 RP: thanks Jun 03 21:47:50 hello! Jun 03 21:47:58 I'm working on BPS, having 3 questions Jun 03 21:48:02 BSP Jun 03 21:48:42 1. I need custom toolchain for my platform, how to "connect" it to the yocto target Jun 03 21:50:06 [Sno]: hi! Jun 03 22:38:59 anyone here? **** ENDING LOGGING AT Thu Jun 04 02:59:58 2015