**** BEGIN LOGGING AT Tue Jun 28 02:59:58 2016 Jun 28 04:33:17 anyone here built a cortex-r5 image? Jun 28 06:42:19 hello Jun 28 06:42:38 for a recipe called cornel.bb, how can i found all the .bbappend 's? Jun 28 06:56:28 c0rnel, can you just use "find . -name cornel.bbappend"? Jun 28 07:11:05 redengin, yes i can, but i have 1.5 million files under build/tmp ... Jun 28 07:12:34 find meta-* -name cornel.bbappend"? Jun 28 07:21:52 Hello, i'd like to build a image for a new machine, but meet error with: ERROR: u-boot-v2016.03+gitAUTOINC+df61a74e68-r0 do_compile: oe_runmake failed Jun 28 07:23:29 it seems i need to buid something with uboot, but how can i do it? i did't find info about this on the office site? thanks for help Jun 28 07:25:16 thank you redengin Jun 28 07:26:54 c0rnel, glad it helped, sorry I don't know the bitbake incantation Jun 28 07:30:45 Tab_Liu_hange: yocto is trying to build u-boot for your machine and it is failing Jun 28 07:31:17 the error message normally includes the path to a log.do_compile file; it contains details on the make failure Jun 28 07:35:11 fredcadete: yes, when i buid the meta-machine with 'yocto-bsp' tools, it only let me choose a kernel source but no u-boot source path, where can i set the u-boot source path? Jun 28 07:36:56 Tab_Liu_hange: I don't really know about 'yocto-bsp' tools, sorry Jun 28 07:39:24 Tab_Liu_hange: you could add your own .bb file in your layer, and then use some mechanism like PREFERRED_VERSION_u-boot or PREFERRED_PROVIDER_virtual/bootloader to force your version Jun 28 07:40:22 Tab_Liu_hange: maybe there are cleaner ways to do it, dunno Jun 28 07:40:50 fredcadete: i use command 'yocto-bsp create machine arm' to build a meta-machine first Jun 28 07:41:35 fredcadete: then try to use 'bitbake core-image-minimal' to build a image. Jun 28 07:42:56 fredcadete: so, i should touch a new .bb file to set the path of the u-boot source. Jun 28 07:45:25 Tab_Liu_hange: you could try that, but I don't see how just a 'touch' would work Jun 28 07:46:07 the machconfig inside the bsp layer is usually how you control uboot configuration Jun 28 07:46:40 fredcadete: ok, thank you very much Jun 28 07:51:18 redengin: thanks for info Jun 28 08:06:51 So I'm now looking into using bitbake to build a system without oe-core or any existing yocto related layers Jun 28 08:07:11 I started by following this (oldish I think) tutorial: http://a4z.bitbucket.org/docs/BitBake/guide.html ... Jun 28 08:08:05 but now I realize, the bitbake codebase itself seems to lack the simplest/common classes one would regularly use, i.e. autotools and such Jun 28 08:09:24 So I just wonder, is there some cleaner way to pull in all the useful functionality from say, poky, without burdening the project with all the rest of poky ? Jun 28 08:11:31 actually it looks worse than this, if I pull in poky, the autotools helpers and such seem to be embedded into the base 'meta' layer Jun 28 08:11:51 gtristan: meta = openembedded-core. Jun 28 08:11:55 so I would have to use special care to ensure that recipes from that layer do not contaminate the build right ? Jun 28 08:13:00 You *want* to be based on openembedded-core ;-} Everything else would imply building an entire distro from scratch. Jun 28 08:13:54 actually no I dont, you are right that I *will*, but for right now I want a hack which will take an existing rootfs, writeup one hacky recipe to drop it in place and run the build against that Jun 28 08:13:55 Hmm, sounds like that is indeed your goal. Just beware that even "Tizen on Yocto" didn't do that. Jun 28 08:14:26 Right, tizen to yocto bases some highlevel things on the oe-core rootfs iiuc Jun 28 08:15:09 bitbake and oe-core do not work with an existing rootfs. They need to be able to build that rootfs from recipes. Jun 28 08:15:29 to describe the use case, I have a real mess of a workflow to deal with and a system in production, for which I cant just go replacing components and rebuilding components from the base system Jun 28 08:15:56 and just want to get the workflow of the higher level components setup straight, without changing the base system in any risky way Jun 28 08:16:12 for the later releases, we may well base things on oe-core Jun 28 08:16:57 pohly, you're absolutely sure about that ? I would think one could just extract something with all the dev headers and compilers and all, and build from there no ? Jun 28 08:17:19 even if say; I disabled cross compiling completely, and extracted it twice (once for 'build' and once for 'target') Jun 28 08:18:48 seems like it should be a simple enough trick... but then, if I want to use the rpm disting support (which unfortunately I think we'll want), I may have to use the rpm built by yocto, again contaminating the build :-S Jun 28 08:19:13 Yes, I'm pretty sure. Or if there is a way, then I don't know how to do it. To me it seems to go against the entire purpose of the tools. Jun 28 08:20:33 Well, the question is how do you transition a company with an existing product in production to a new tooling, it sort of sucks to say; you can use this completely new workflow for your devel branch (to be released in 2 years), but you're stuck with your current production mess until then Jun 28 08:23:17 I think, 'building that rootfs from recipes' should be able to equate to 'provide a recipe that just does tar -zxf rootfs.tgz' and have all your layers depend on that roofts.bb Jun 28 08:25:11 at face value, that sounds pretty straightforward, I just wonder about 'build depending' on other tooling; that can end up pulling in the wrong compiler etc; so I guess I would have to re-implement any bbclasses that I intend to use on top of the same rootfs Jun 28 08:40:41 good morning Jun 28 10:02:42 Hi, I'm having probs building an image at the do_rootfs stage, where I get Jun 28 10:02:45 Computing transaction...error: Can't install qtwayland-5.5.1+git0+9d40864945-r0@cortexa7hf_vfp_vfpv4_neon: no package provides libQt5Quick.so.5 Jun 28 10:03:46 I've tried deleting the tmp directory, cleans and cleansstage on the top level and on qtquick1 but keep getting this failure Jun 28 10:04:39 The problem may originate from the build partition going read-only due to a problem with the virtual machine I'm building it on but working out what that caused is giving me problems Jun 28 11:33:31 is it possible to access a variable contained in WICVARS from a .wks file ? Jun 28 11:33:45 looking at wic code I can only access them from a .py file... Jun 28 13:34:54 I am looking for a hint how to debug this problem (leading to several not found python modules): /opt/ngt/yocto/build/poky/bitbake/bin/../lib/bb/event.py:118: RuntimeWarning: Parent module 'bb' not found while handling absolute import from bb.msg import BBLogFormatter, full log here: https://paste.kde.org/pxma1ddmc Jun 28 13:41:25 CoLa|work: i'm guessing you should speak to mentor about that, as its failing in their code Jun 28 13:41:32 kergoth: ^ Jun 28 13:50:42 rburton: thanks, actually just found out that I missed updating a git submodule... seems that a too old poky got into my way Jun 28 16:23:18 hi all.. someone familar with unittest (testimage)? i a wondering why testcase are executed in random order altough we set testcase(1.2) and testcase(1.3) in our python unittest script.. also wondering why skipUnlessPassed not working within the module, see here: http://pastebin.com/QRCHe4LT Jun 28 16:23:38 any idea? Jun 28 16:23:58 skipunlesspassed works for me Jun 28 16:24:23 rburton: also for testcases that are defined in the same file? Jun 28 16:24:34 yeah Jun 28 16:25:32 so that means, it should first execute testcase(3) before testcase(3.1) here: http://pastebin.com/raw/QRCHe4LT ?? Jun 28 16:27:37 i do not understand why it is not working for me Jun 28 16:27:52 @skipUnlessPassed(3) looks wrong Jun 28 16:28:23 yes sure.. but pls see testcase(3.1) Jun 28 16:28:25 but afaik that should work Jun 28 16:28:45 maybe there's a bug there in that ordering needs to be explicit, like what happens if you tell it to run the tests in the order you want them to happen Jun 28 16:30:28 if i remove skipUnlessPassed('test_net_log_ifconfig') .. why the test are not executed in order 3 -> 3.1 -> 3.2 ? Jun 28 16:30:43 why would they? Jun 28 16:30:57 @testcase is just to map tests to entries in the yocto test plan Jun 28 16:31:27 so it is expected that they are run randomly? Jun 28 16:31:33 okay.. so i need skipUnlessPassed Jun 28 16:31:55 they are ran in the order that python's unittest framework wants to execute them in Jun 28 16:35:25 rburton: i started a clean test script file.. now it work.. some typo or something.. thanks Jun 28 16:35:51 i will double-check Jun 28 16:37:22 no.. does not work.. it seems to be alphabetical order.. Jun 28 16:37:41 strange, even using skip Jun 28 16:37:55 as i said, skip probab;y doesn'y impact ordering Jun 28 16:38:32 but hey.. if i say skip.. it should skip until the other test ends right? :) Jun 28 16:38:44 so that is an order Jun 28 16:39:30 sure, it's broken. never really liked it. Jun 28 16:40:00 just use unittest functions, and write atomic tests that don't have ordering requirements Jun 28 16:41:05 but it should work for the @skipUnlessPassed("test_ssh") -- otherwise it will not work at all.. so seems to work for this?! Jun 28 16:44:05 test_ssh probably ran already Jun 28 16:44:49 rburton: true Jun 28 18:44:54 hello Jun 28 18:45:51 I'm trying to repull some source for u-boot. I did $bitbake u-boot -c fetch, but it says task didn't need to be rerun. How can I force it to rerun? Jun 28 18:47:18 see bitbake --help Jun 28 18:48:38 -f ? Jun 28 18:49:07 yes Jun 28 18:49:41 oddly that says same thing. maybe its the order of the commands. let me try to move it earlier in command. Jun 28 18:50:05 nope Jun 28 18:50:34 NOTE: Tainting hash to force rebuild of task Jun 28 18:50:37 but then later Jun 28 18:50:43 Attempted 1 tasks of which 0 didn't need to be rerun and all succeeded. Jun 28 18:51:21 -f forces the task specified in -c to run. if -c isn't specified, it'll force the re-run of do_build, which will basically do nothing Jun 28 18:51:27 order is irrelevent Jun 28 18:51:37 $ bitbake -f u-boot -c fetch Jun 28 18:52:03 it says do_fetch is the task Jun 28 18:52:32 if I use download instead, it says do_download does not exist for target Jun 28 18:52:44 there's no such thing as download, no idea where you got that from Jun 28 18:53:14 I guessed since fetch did not work Jun 28 18:53:34 pulling random words out of a hat isn't going to magically fix it Jun 28 18:53:42 try -C fetch instead of -f -c fetch Jun 28 18:54:03 -C does it. Jun 28 18:54:09 many thanks Jun 28 18:55:30 you have made my day! Jun 28 18:55:51 np Jun 28 19:11:54 kergoth: years ago that idea of wrting bitbake on golang was a good one Jun 28 20:02:07 does anyone know if there is a command in bitbake that will list all packages and licenses ? Jun 28 20:17:57 bottazzini: not aware of one. See the section in the manual on license compliance though, if you're interested in that. Jun 28 20:18:47 neverpanic, I will thanks Jun 28 20:20:26 bottazzini: you can use bitbake-layers show-recipes Jun 28 20:20:41 that will atleast show you recipes available in your layermix Jun 28 20:21:17 khem, cool Jun 28 20:21:34 thanks :) Jun 28 20:21:38 it does not have licence info, it may be a good enhancement though Jun 28 20:21:54 I would encourage you to file an enahancement request on bugzilla Jun 28 20:22:19 there is info on licences in manifests of generated images though Jun 28 20:22:39 khem, I will do it... yes I saw there are folder with the licenses right ? Jun 28 20:22:49 yes Jun 28 20:22:54 I was thinking in creating a script to parse this kind of thing to mee Jun 28 20:22:56 me* Jun 28 20:23:19 I will file the enahancment too Jun 28 20:29:24 license.manifest in tmp/deploy/licenses// Jun 28 20:29:45 has info on output packages and their governing licenses which go into the image Jun 28 21:47:26 this should be trivial but its not for me. Jun 28 21:47:45 I have a set of patches for u-boot, which look like they were created from a git repo Jun 28 21:48:15 I simply modified the file in the temp build dir to get it to build Jun 28 21:48:40 I want to make a patch file to add to the src dir where all the other patches go Jun 28 21:50:31 davis: to create the patch you need the original and the modiffied file, so you execute the command diff -up original modified Jun 28 21:50:52 so you create a bbappend for u-boot Jun 28 21:51:11 so even if its a non git based patch, i can use it with the other patches? Jun 28 21:51:21 yes Jun 28 21:51:27 many thanks Jun 28 21:51:28 depends Jun 28 21:51:40 when the patch need to be applied Jun 28 21:52:11 after the do_patch task, the bitbake executes the task do_patch Jun 28 21:52:21 that applies every patch file in the SRC_URI Jun 28 21:52:47 so it is before the commands do_configure, do_compiles, etc Jun 28 21:53:22 so if the patch is applied in a file that is generated in this other tasks, you must do some workarounds, that is more difficult Jun 28 21:53:25 but if is not Jun 28 21:53:31 you just need to create a bbappend Jun 28 21:53:38 add in the SRC_URI your patch Jun 28 21:53:56 I was just going to add it in the existing dir with the other patches Jun 28 21:54:10 and then modify the existing .bb file to add the new patch Jun 28 21:54:32 and append your dir to the FILESEXTRAPATHS Jun 28 21:55:02 yes, but this modifications will not be versioned Jun 28 21:55:29 the yocto way is make a bbappend Jun 28 21:55:36 but you can do this way too Jun 28 21:56:14 will work Jun 28 21:56:26 but you need to add the file in the SRC_URI Jun 28 21:56:40 ok, that is a lot to digest Jun 28 21:56:48 you can look in the yocto's tutorial how to make a bbappend Jun 28 21:56:53 let me see what i can do based upon your suggestions Jun 28 21:57:10 you have given me some good advice, thank you. Jun 28 21:57:23 FILESEXTRAPATHS_append := "${DEPLOY_DIR_IMAGE}:" Jun 28 21:57:32 ops Jun 28 21:57:37 http://www.yoctoproject.org/docs/1.6/dev-manual/dev-manual.html#using-bbappend-files Jun 28 21:57:49 fwiw, once i have it in place, the method to test it is: $bitbake -C patch -f u-boot Jun 28 21:58:42 bitbake -c patch u-boot Jun 28 21:59:01 capital c or lowercase c? Jun 28 21:59:09 do bitbake -c cleansstate u-boot before Jun 28 21:59:18 lowercase Jun 28 22:01:58 well this vendor modified thing does not work Jun 28 22:03:03 i get this problem from time to time Jun 28 22:03:18 even thought the export MACHINE=foo is done Jun 28 22:03:37 how did you do that? Jun 28 22:03:38 it will fails and say it can't find the correct arch file Jun 28 22:03:53 so I have to rebuild from start Jun 28 22:04:02 i did not make this setup Jun 28 22:18:45 igor3: it looks like it is "working" Jun 28 22:18:59 I got the patch file in the correct format. Jun 28 22:19:24 to avoid the arch config file error, I have to use the high level target to build everything Jun 28 22:19:36 ok, now you can follow the tutorial and make it Jun 28 22:19:54 this vendor modified setup does not seem to work well with individual targets/tasks. Jun 28 22:20:16 what errors are you getting? Jun 28 22:20:55 right now, i have no errors, its building Jun 28 22:21:03 however, i had two earlier errors Jun 28 22:21:11 one is that the u-boot needed a patch Jun 28 22:21:18 i added the patch file Jun 28 22:21:41 but the second error was that when I tried to test it by doing bitbake -c patch u-boot Jun 28 22:21:50 it failed with a config error Jun 28 22:22:17 however, if I bitbake high-level-image-name Jun 28 22:22:33 it gets resolved for config file and actually starts building Jun 28 22:22:52 i am pretty sure this is due to the vendor changes to yocoto Jun 28 22:25:55 are you cleaning the sstate before testing? Jun 28 22:26:06 bitbake -c cleansstate u-boot Jun 28 22:26:33 yes Jun 28 22:26:44 it detects it needs to be rerun Jun 28 22:27:05 its just that specifying a particular task does not work for some tasks Jun 28 22:27:20 for those you need to specify the high level task Jun 28 22:27:23 yes, because some taks depends on others **** ENDING LOGGING AT Wed Jun 29 02:59:58 2016