**** BEGIN LOGGING AT Wed Dec 09 03:00:26 2015 Dec 09 09:28:33 So, I'm trying to generate a diskimage using `poky/scripts/wic create directdisk ....`. This has worked for me after various failed attempts. Thing is that I managed to do it without installing `parted` on my host and now when trying to generate the image again on a clean environment, it says that it needs it. Dec 09 09:30:34 I've discovered that before trying find parted on my host, it tries to open 'poky/scripts/parted'. I guess I somehow managed to generate that script at some point. Dec 09 09:30:45 Does anybody know what do I have to do to make that happen? Dec 09 09:31:18 (i.e. generate 'poky/scripts/parted' so that I don't have to intall parted on my host?) Dec 09 14:17:58 hello! anyone have any experience creating recipes for a project that builds with python? Dec 09 14:20:11 tobias_: do you mean creating recipes for python modules? Dec 09 14:21:02 i want to create a recipe for ubuntus onboard virtual keyboard, it depends on python-distutils-extra, i cant import this into yocto env Dec 09 14:22:38 it uses the python from yocto, i need to export the environment from my /usr/lib/python.. where the distutils-extra is installed Dec 09 14:25:11 ive been looking for a similar recipe that builds an python application but i cant find one, anyone have an idea about this = Dec 09 14:25:13 ? Dec 09 15:02:30 whats the correct way to tell a recipe to compile with the build host version of python ? Dec 09 15:02:58 rburton: please drop tune changes from mut, I've found more issues in old tune files and refactored it a bit to prevent further issues like this, latest patchset I'm testing is here: http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune3 Dec 09 15:03:14 test script and results for various stages still in jansa/tune2-test branch Dec 09 15:04:05 JaMa: dropped already, butt thanks. Dec 09 15:04:28 tobias_: thats the python that will be used unless you say otherwise Dec 09 15:06:39 rburton: but why can i build the package "outside" of yocto and not "inside"? Dec 09 15:07:11 rburton: the module is missing when building the recipe but not when i manually build it Dec 09 15:07:47 concrete examples might help Dec 09 15:08:06 oe builds lots of python stuff so it clearly can be done Dec 09 15:10:05 rburton: i want to build onboard (ubuntu default virtual keyboard) with yocto for a system running cef Dec 09 15:10:59 rburton: onboard depends on python-distutils-extra, i have this installed Dec 09 15:13:21 is there a reason you don't just make a distutils-extra recipe and get on with your day? Dec 09 15:13:44 did that, Dec 09 15:13:51 did not work .. Dec 09 15:13:53 in which case you'll want to inherit pythonnative Dec 09 15:14:08 as you're now asking the system to use python modules that are *not* installed on the host Dec 09 15:14:23 did that to, still missing the module Dec 09 15:14:27 (and depend on python-distutils-extra-native) Dec 09 15:14:36 "did not work" is not useful information Dec 09 15:15:18 inherit python3native did not work Dec 09 15:15:21 its entirely possible that the onboard build is using /usr/bin/python somewhere and so not using the modules you want it to Dec 09 15:17:24 the first line of setup.py tries to import distutils-extra but fails Dec 09 15:17:32 and what python does that run in? Dec 09 15:17:38 python3 Dec 09 15:17:46 check what actual binary Dec 09 15:18:02 if its running the one in /usr/bin then it won't see the modules installed by your recipes Dec 09 15:18:12 my train has arrived, time to go Dec 09 16:14:14 http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-DATETIME Dec 09 16:14:31 "Current build" -- build of a recipe or bitbake invocation Dec 09 16:14:32 ? Dec 09 16:15:11 i.e., if I do bitbake my-image and I'm timestamping something in an image, is it guarenteed that DATETIME will be the sampe in do_compile and do_deploy? Dec 09 16:15:27 s/in an image/in a recipe/ Dec 09 16:22:57 DATETIME is expanded early at parse time, it doesnt change after that Dec 09 16:23:09 so as long as do_compile and do_deploy both run in the same bitbake invokation, yes Dec 09 16:23:23 kergoth: Thanks for confirming Dec 09 16:23:42 np Dec 09 18:56:49 Hi all, I'm having an issue getting cmake working on a custom recipe: https://gist.github.com/kratsg/ec5b45917172268e9e5b Dec 09 18:58:36 The recipe is here: https://github.com/kratsg/meta-l1calo/blob/master/recipes-core/root/root_6.04.12.bb Dec 09 19:03:58 LICENSE = "Unknown LGPLv2.1" Dec 09 19:04:08 change that to LICENSE = "LGPLv2.1" Dec 09 19:05:15 real issue although is this Dec 09 19:05:15 Could not find compiler set in environment variable FC: Dec 09 19:05:23 Yeah, that's what's strange. Dec 09 19:05:29 so it seems to be needing a fortran compiler Dec 09 19:05:33 I keep looking at the patch reports and it seems like that was patched in 2013. Dec 09 19:05:44 (FC should be set) so I'm not sure why it isn't. Dec 09 19:06:39 This seems to claim it needs to be set from FC: https://root.cern.ch/building-root Dec 09 19:08:22 and here is homebrew's equivalent recipe (which is where I based most of the cmake commands off of) https://github.com/Homebrew/homebrew-science/blob/d6864830023af55a2c28efbe48542de3c40565e9/root6.rb Dec 09 19:09:34 I wonder if it's because of the missing `std_cmake_args` which probably contains the fortran link. Dec 09 19:12:01 and that is defined here: https://github.com/Homebrew/homebrew/blob/master/Library/Homebrew/formula.rb#L1035-L1051 Dec 09 19:12:28 So nope, I don't know for sure how to set FC correctly within bitbake. Dec 09 19:16:29 in recipe you can pass it via EXTRA_OECMAKE Dec 09 19:16:36 FC="" Dec 09 19:16:40 might be enough Dec 09 19:19:25 set it to nothing? Dec 09 19:22:58 Maybe do_configure(){ export FC="${GFORTRAN}" } will be enough? Dec 09 19:23:14 i don't know if that uses the cross-compiler fortran Dec 09 19:27:45 if this component needs fortran then you better enable this lang frontend in gcc recipes first Dec 09 19:27:54 but if its just a config check Dec 09 19:27:58 then feed anything into it Dec 09 19:28:30 well, it uses fortran to compile... Dec 09 19:28:34 not to run. Dec 09 19:29:24 from what I can tell, enabling in gcc means fortran is on the board which I don't want/need. This is a cross-compiling issue. Dec 09 19:29:57 Ok, it looks like cmake is broken? Dec 09 19:30:09 It's complaining that `make install` doesn't work -- but it should be using cmake Dec 09 19:36:02 adding `-DCMAKE_Fortran_COMPILER=${GFORTRAN}` still has a complaint about FC not being set. So it looks like that doesn't work and I'll need to set it in a do_configure_prepend() Dec 09 19:52:24 ok, now C++11 issues! https://gist.github.com/kratsg/cd3184a167676eb69067 Dec 09 19:52:38 the current file looks like this: https://github.com/kratsg/meta-l1calo/blob/master/recipes-core/root/root_6.04.12.bb Dec 09 20:51:53 How do i remove (make it not applied) a patch from a bbappend file? Dec 09 20:52:26 http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-devtools/python/python3/04-default-is-optimized.patch Dec 09 20:52:30 easiest would be to remove it from SRC_URI, could use _remove, oe_filter_out, or anonymous python Dec 09 20:52:34 in particular, i want this gone Dec 09 20:54:02 SRC_URI_remove = "file://04-default-is-optimized.patch" Dec 09 20:54:03 ? Dec 09 21:21:04 alexlarsson: yep Dec 10 00:31:12 say someone did something foolish like delete a git branch from their buildhistory/.git directory accidentally on purpose Dec 10 00:31:52 is there a relatively safe way to reset or zero out said .git directory? Dec 10 01:29:17 deviosity: hmm, I'm not too familiar with the internal structure of .git... being only a branch I'm assuming it's just a pointer to a hash Dec 10 01:30:14 deviosity: which file(s) did you delete exactly? Dec 10 01:30:14 blowing out the build history was pretty safe for me Dec 10 01:30:26 right, if you don't care about it you can just delete everything Dec 10 01:30:45 I was doing some kernel development, and used a wrong commit hash Dec 10 01:30:46 another alternative would have been to just delete the .git and re-create it with an initial commit at the current state Dec 10 01:30:51 so ctrl+c'd it Dec 10 01:31:33 it was causing all sorts of odd errors, still taking up GBs of space, so I did a find on the errors bitable was displaying, and finally deleted it Dec 10 01:31:42 not really thinking there would be repercussions Dec 10 01:32:57 build history was a nice to have, not a end of world if it was reset, so I'm all good. Dec 10 01:33:19 bluelightning: thanks for trying to help. Dec 10 01:33:38 no problem :) Dec 10 01:35:08 * deviosity needs to remember to disable autocorrect. **** ENDING LOGGING AT Thu Dec 10 02:59:59 2015