**** BEGIN LOGGING AT Thu Apr 27 03:00:00 2017 Apr 27 06:13:22 Hello! Any ideas why I'm failing to build an image for beagleboard? I cloned the poky-repo, run the oe-init-build-env -script, changed the machine to beagleboard and run bitbake core-image-base. What I got was an error about do_image_wic. Apr 27 06:14:33 ERROR: core-image-base-1.0-r0 do_image_wic: Function failed: do_image_wic (log file is located at /home/ilari/poky/build/tmp/work/beaglebone-poky-linux-gnueabi/core-image-base/1.0-r0/temp/log.do_image_wic.57080) Apr 27 06:14:37 ERROR: Logfile of failure stored in: /home/ilari/poky/build/tmp/work/beaglebone-poky-linux-gnueabi/core-image-base/1.0-r0/temp/log.do_image_wic.57080 Apr 27 06:14:40 Log data follows: Apr 27 06:14:43 | DEBUG: Executing python function set_image_size Apr 27 06:14:45 | DEBUG: Python function set_image_size finished Apr 27 06:14:48 | DEBUG: Executing shell function do_image_wic Apr 27 06:14:50 | Warning: bootloader config not specified, using defaults Apr 27 06:14:53 | Error: exec_cmd: install -m 0644 -D /home/ilari/poky/build/tmp/deploy/images/beaglebone/u-boot.img /home/ilari/poky/build/tmp/work/beaglebone-poky-linux-gnueabi/core-image-base/1.0-r0/deploy-core-image-base-image-complete/core-image-base-beaglebone-20170426102250/build/boot/u-boot.img returned '1' instead of 0 Apr 27 06:14:58 | Checking basic build environment... Apr 27 06:15:00 | Done. Apr 27 06:15:03 | Apr 27 06:15:05 | Creating image(s)... Apr 27 06:15:08 | Apr 27 06:15:10 | WARNING: exit code 1 from a shell command. Apr 27 06:15:13 | ERROR: Function failed: do_image_wic (log file is located at /home/ilari/poky/build/tmp/work/beaglebone-poky-linux-gnueabi/core-image-base/1.0-r0/temp/log.do_image_wic.57080) Apr 27 06:15:16 ERROR: Task (/home/ilari/poky/meta/recipes-core/images/core-image-base.bb:do_image_wic) failed with exit code '1' Apr 27 06:15:19 There is the error-message. Apr 27 06:20:59 muumio: looks like the wic script has some issues. is this master, or some specific revision? Apr 27 06:21:37 I'm using morty. Apr 27 06:24:17 muumio: ok. i can try to reproduce it, but will take some time. Apr 27 06:24:38 Excellent! Thank you. Apr 27 06:25:59 you didn's set anything manually besides MACHINE = "beaglebone", right? Apr 27 06:29:17 I just uncommented the #MACHINE ?= "beaglebone" -line and changed the PACKAGE_CLASSES to "package_deb" Apr 27 06:29:31 Nothing else. Apr 27 06:30:25 ok. i just kicked off a core-image-minimal and will see. Apr 27 06:31:33 Great! Apr 27 06:37:13 I still can't make work pygtk, I need to know if there is a package with pygtk as dependencies. Like this I can install the package and pygtk will be included.. Apr 27 06:41:44 hamdyaea: Try to install python-gtk2-dev Apr 27 06:47:32 muumio: I try to replace it with python-pygobject, if it's not working I will try python-gtk2-dev Apr 27 07:27:35 muumio: here, the build showed no errors. :-/ Apr 27 07:30:03 Hmm. Weird. I actually have no idea what to try next. Google knew nothing. I'm running Ubuntu 16.4 on a virtual machine but cannot imagine it has anything to do with this. Apr 27 07:30:36 muumio: you didn't run out of memory, enough ram+disk? no earlier errors or such? Apr 27 07:31:28 No. But I get two warnings before: Apr 27 07:31:45 WARNING: libpng-native-1.6.24-r0 do_fetch: Failed to fetch URL http://distfiles.gentoo.org/distfiles/libpng-1.6.24.tar.xz, attempting MIRRORS if available Apr 27 07:31:49 WARNING: apt-native-1.2.12-r0 do_fetch: Failed to fetch URL http://snapshot.debian.org/archive/debian/20160526T162943Z/pool/main/a/apt/apt_1.2.12.tar.xz, attempting MIRRORS if available Apr 27 07:31:59 those should be non-critical. Apr 27 07:32:16 That's what I thought too. Apr 27 07:33:34 so you really, really, really did no more than 1) clone poky and checkout the morty branch 2) source oe-init-env 3) enter the build dir 4) modify conf/local.conf to MACHINE = "beaglebone" and PACKAGE_CLASSES = "package_deb" 5) start the build? Apr 27 07:33:42 no additional layers, etc? Apr 27 07:34:20 Nope. Just what you described above. Apr 27 07:34:29 ok. what image are you trying to build? Apr 27 07:35:05 It's the base-image. Apr 27 07:35:40 muumio: So you haven't added any of the Mender stuff yet? Apr 27 07:35:48 muumio: base-image? Apr 27 07:35:56 core-image-base Apr 27 07:36:03 (instead of core-image-minimal) Apr 27 07:36:30 JoiF: i would assume that too, but is it really what muumio is trying to build? Apr 27 07:36:42 LetoThe2nd: That's what I wrote above :) Apr 27 07:36:46 blah Apr 27 07:36:47 HE Apr 27 07:37:08 JoiF: ah you're reight Apr 27 07:37:36 ok kicked that off too Apr 27 07:37:57 I just tried with core-image-minimal as well with same results. Apr 27 07:38:52 muumio: what about the cpu/memory setup of your vbox? Apr 27 07:39:01 has this something to do with failure? Warning: bootloader config not specified, using defaults Apr 27 07:39:51 muumio: yeah i suspect it has got something to do with it. but if you didn't modify anything, then whoy should it trigger only there? Apr 27 07:41:42 Good question... Apr 27 07:44:27 succeeds too. Apr 27 08:41:14 Currently 107 running tasks (19885 of 34001) Apr 27 08:41:25 * RP wonders if this build might actually work out Apr 27 08:42:06 (multiple TMPDIRs, DISTROS and MACHINEs) Apr 27 08:43:02 hehe sounds like pretty big iron Apr 27 08:45:22 :) Apr 27 08:45:38 is there a way to run stuff simultaneously by now? or is this more like a bibake server and stuff just got queued up? Apr 27 08:46:05 LetoThe2nd: BBMULTICONFIG does make some things possible but it does have some bugs too Apr 27 08:46:59 LetoThe2nd: you can do multiple MACHINE in one build. With a small patch, different TMPDIR/DISTRO appears to work Apr 27 08:47:43 RP: ah ok gotcha. i don't have a specific use case, just sounded interesting :) Apr 27 08:48:38 LetoThe2nd: it is interesting to see what I can push this hardware too :) Apr 27 08:48:49 So, I increased VMs hd to 200G, ram was 8G which should be fine but build still fails. Apr 27 08:48:56 LetoThe2nd: I think the answer is bottlenecks in bitbake itself sadly Apr 27 08:49:14 I guess I have to try with fresh clone... Apr 27 08:49:14 RP: time to dig out the algorithms book and review the scheduler etc? Apr 27 08:49:15 RP: yeah 100 tasks is kinda impressive. some 16 socket xeon? Apr 27 08:49:38 rburton: its not the scheduler, its the logging pipes to the server Apr 27 08:49:47 ah Apr 27 08:50:00 LetoThe2nd: dual socket xeon (88 core) Apr 27 08:50:22 muumio: and the git clone was really fresh? directly from git.yoctoproject.org, and directly checked out morty then? Apr 27 08:50:47 Yep. Apr 27 08:50:59 RP: ah 2 sockets * 22 cores * 2 HT, right? Apr 27 08:51:06 LetoThe2nd: right Apr 27 08:51:10 muumio: no idea then sorry. Apr 27 08:51:21 RP: sounds fun. :) Apr 27 08:51:33 But I'll try again and get back to it. Although, it takes few hours with VM. Apr 27 08:51:51 LetoThe2nd: load avg of 250+ and its 50% idle :/ Apr 27 08:52:09 RP: hey don't make me feel so bad with my 32way!! Apr 27 08:52:29 LetoThe2nd: you did ask ;-) Apr 27 08:52:59 RP: the next time i ask you something, remind me to not ask you something again Apr 27 08:53:14 nah just kidding. i know how you feel :) Apr 27 08:53:42 though for the build size it might be hard to keep stuff in ram. Apr 27 08:54:11 LetoThe2nd: I'm just amazed a simple patch actually made this build combination work. its not mergeable but gives me hope about crazy things we can enable with multiconfig Apr 27 08:54:35 LetoThe2nd: lets just say I doubt its using the disk ;-) Apr 27 08:54:59 * LetoThe2nd is usually inclined to consider all the stuff we do rather crazy, so i reinterpret that as "more crazy things we can enable" Apr 27 08:56:33 One of the things I have to do alongside my work with Yocto is to document how to do.. everything.. (git clone poky, layers, etc.) Now there's a bitbake-layer add command which is nice (means I can replace one of my sed-lines in the documentation with this simpler approach), but is there something now to set what the default machine should be? Currently I have a sed-line for that: sed -i "/edgerouter/aMACHINE ?= \"mud-zynq7\"" conf/local.conf Apr 27 08:57:27 JoiF: usually people use some kind of scripting/tooling to automate that. the common thing theses days seems to be repo Apr 27 08:58:19 JoiF: we're using a custom script, see https://github.com/LetoThe2nd/blubber Apr 27 08:58:40 though a rewrite is certainly due some time soon. Apr 27 08:59:35 Ahh, nice Apr 27 08:59:36 Ok Apr 27 09:01:02 LetoThe2nd: Btw, you can replace your "LINEFEED" with os.linesep .. or initialise LINESEP as LINESEP = os.linesep Apr 27 09:01:26 JoiF: the python is awful and i know it :) Apr 27 09:01:47 LetoThe2nd: Got that from the README.md ;) Apr 27 09:02:08 LetoThe2nd : It's because you're not used to :D Apr 27 09:02:18 JoiF: it was just my toy project to tinker and learn python and it kinda crept into production here. :-) i'm free to share it so if you can use bits and pieces, go ahead and have fun. Apr 27 09:03:18 s/LINESEP/LINEFEED/g in me previous statement Apr 27 09:03:32 LetoThe2nd : there is already companies doing that, you can inspire from them Apr 27 09:04:25 ChrysD: there is absolutely enough inspiration out there. the architecture for the rewrite is already in my head, its just hte time that i lack. Apr 27 09:05:26 LetoThe2nd : btw, nice project and have fun. Apr 27 09:05:34 thx Apr 27 09:05:51 Yeah, it's nice :) Apr 27 09:06:33 LetoThe2nd : but I disagree with the name ahahah Apr 27 09:07:33 the name comes from the german idiom "vor sich hin blubbern" Apr 27 09:08:23 I understand more now ahah Apr 27 09:09:02 because you start it, and then "blubbert es vor sich hin" Apr 27 09:10:24 You seems proud of the name, maybe more than the project ! Apr 27 09:10:53 Its in keeping with the project naming theme :) Apr 27 09:11:30 doesn't translate brilliantly as "blubber" is quite different in English... Apr 27 09:11:53 it's more than " quite " different :p Apr 27 09:12:10 RP: i know, and the pun actually is intended (as its kinda a layer of fat around the workings of bitbake) Apr 27 09:12:34 LetoThe2nd: I wondered :) Apr 27 09:13:18 looking at the code these days i'm kinda convinced that the only thing i really got right is the name. Apr 27 09:14:05 LetoThe2nd : +1 Apr 27 09:14:53 i mean, i dislike the concept and usage of repo for a reason. but TBH, for most people its a vastly superior fit than my toy script. Apr 27 09:15:12 Could you explain more ? Apr 27 09:15:51 what exactly? Apr 27 09:16:13 Why you dislike the concept and usage of repo Apr 27 09:16:52 my main problem with repo is that its not self contained. Apr 27 09:17:23 +1 Apr 27 09:17:34 you download a wrapper script, which then clutters your ~/bin by default Apr 27 09:19:18 plus, its focus is on managing the state of the git clone tree. the focus of the tolling i would like is assisting the common bitbake tasks Apr 27 09:20:07 LetoThe2nd: FWIW in 2.4 we are thinking about some kind of setup tool in bitbake itself Apr 27 09:20:27 RP: yeah we were discusing stuff in berlin Apr 27 09:20:52 LetoThe2nd: right, that continued at ELC too Apr 27 09:21:06 Is it really a bad things that repo aren't self contained ? I consider that as supermarket which you take ingredient. But you still need to know how to cook them and the ingredients in supermarket doesn't come with tools as knife. Apr 27 09:22:17 RP: noticed the discussion on -arch. its just that frays thing has a different use case again (setting up the initial project, not the workspace). and given the awful state of blubber i did not throw it in. Apr 27 09:22:47 LetoThe2nd: so many different things people want from it :) Apr 27 09:23:43 RP: if i had a good idea, i would gladly offer it. and a possible rewrite will certainly be out for everyone who wants to use it a again - but what i envision is .. kinda incompatible with what YÖP sees as a good code base. Apr 27 09:24:44 ChrysD: i did not say it is bad, did i? i said "i dislike it" Apr 27 09:24:55 LetoThe2nd: having some kind of standard in the core is looking sensible, I very much doubt it will work for everyone and we won't be "mandating" it, just encouraging to use where possible :) Apr 27 09:24:55 completely different meaning. Apr 27 09:25:17 RP: brace yourself: rewrite will be node.js and using json as config files. Apr 27 09:25:52 LetoThe2nd: have fun ;-) Apr 27 09:26:15 RP: will do :) Apr 27 09:31:59 You mean rewrite of your own code ? Apr 27 09:33:16 yes of course. Apr 27 09:36:49 I have an odd issue with doing a rootfs for a core2-32 target. I am using opkg and the opkg.conf has core2-32 Apr 27 09:37:12 I have a "kbd_2.0.4-r0.0_core2-32.ipk", it seems in the Packages file Apr 27 09:37:26 Problem 1/1: Apr 27 09:37:27 - nothing provides kbd needed by keymaps-1.0-r31.0.sysmocom_idu Apr 27 09:43:34 http://paste.lisp.org/display/345264 is there anything obvious in it? Apr 27 09:47:21 RP: In staging.bbclass there is support for fixing up paths after restoring the files from the sstate cache. Could/should this also fixup references to tmp/hosttools? Case in hand: we have native tool written in perl. It uses autoconf to configure, an there they use AC_PATH_PROG(PERL, perl) to find the path to perl. This path is used in the shebang line of the installed tool. With Morty and earlier this worked as expected, with /usr/bin/perl ending up Apr 27 09:48:28 RP: For now I have solved it in the recipe with CACHED_CONFIGUREVARS += "ac_cv_path_PERL=${USRBINPATH}/perl" but a generic solution would be preferred. Apr 27 09:57:30 kanavin: "i can only see pain and suffering" ;-) Apr 27 09:59:59 LetoThe2nd: that's a Depeche Mode reference, sort of Apr 27 10:00:26 they subtitled one of their records 'pain and suffering in various tempos' Apr 27 10:00:41 i found it very poetic. Apr 27 10:01:02 we could also play master and servant here... Apr 27 10:15:54 LetoThe2nd (and others), so continuing with the repo and blubber discussion: Since repo doesn't seem to support executing any automation (such as sed-ing local.conf or bblaysers.conf, etc. when it's done cloning repositories), is it considered appropriate to put yourPoky/build/conf under SCM and then have repo download that? Apr 27 10:16:43 is there a quick way to see a list of what depends on a recipe? Apr 27 10:17:31 hm i should make pkgdataui do that Apr 27 10:17:45 black list the recipe and do a world build? :) Apr 27 10:18:12 rburton: yeah, but quicker still ;) Apr 27 10:18:15 taskexp should be able to show you if you invoke it on world Apr 27 10:18:20 rburton: just doing that now Apr 27 10:19:03 ah, bb has a what-depends command Apr 27 10:23:33 Saur: it should be possible to use that, yes. SSTATE_SCAN_FILES_append = " scriptname" maybe? Apr 27 10:24:27 RP: Ok, will try that... Apr 27 10:24:57 rburton: how do you invoke that? Apr 27 10:25:32 kanavin: bb whatdepends glib-2.0, but it crashes, obviously this hasn't been updated since the tinfoil changes Apr 27 10:25:51 rburton: bb: command not found Apr 27 10:29:25 kanavin: its on github Apr 27 10:29:59 okay it is a libsolv issue.. Apr 27 10:30:06 hello, just a question about curlpp Apr 27 10:30:39 RP: Adding SSTATE_SCAN_FILES += "" made no difference. The shebang line is still wrong when the tool is restored from sstate... Apr 27 10:31:25 I have added curlpp recipe to core-image-sato but appear "ERROR: curlpp not found in the base feeds" Apr 27 10:31:40 any clue about the issue? Apr 27 10:31:52 kanavin: basically bbcmd in bb needs porting to the new tinfoil still Apr 27 10:39:50 Saur: is the recipe a target one or a native one? Apr 27 10:40:18 RP: A native, and after looking at sstate.bbclass I realized that SSTATE_SCAN_FILES is not used in that case... Apr 27 10:40:34 RP: Anyway, I am testing a fix for staging.bbclass now... Apr 27 10:44:32 RP: Meh. Why is EXTRA_STAGING_FIXMES used in sstate.bbclass to encode FIXMES for variaous variables, but in staging.bbclass it is hardcoded to only do the reverse for PKGDATA_DIR. Why doesn't staging.bbclass use ${EXTRA_STAGING_FIXMES}? Apr 27 10:44:53 Or am I missing something here? Apr 27 10:47:09 Saur: its all about contexts, we don't have the right data store contexts at the right times to make this work properly :( Apr 27 10:47:47 Saur: was meant to be a generic mechanism which turned out I could fully make work. Its not been important enough to go back and try and fix as yet Apr 27 10:47:56 RP: Hmm, ok. Apr 27 10:49:17 Saur: you're right though, hosttools isn't included in our standard paths, I should have realised that earlier :( Apr 27 10:52:22 RP: I'll see if I can get my fix to work, now that I know about both ends of it... Apr 27 10:52:29 Saur: I'd love to fix the mechanism and extend case by case rather than manipulate all hosttools paths. Last time I looked at it, I couldn't immediately see how though Apr 27 12:16:38 Hi guys : Apr 27 12:17:28 I'm trying to add a driver, that I compile Ok on my labtop but when I put it in yocto it says I can't : Apr 27 12:17:44 error: implicit declaration of function 'ioremap' [-Werror=implicit-function-declaration] | i2s = (volatile struct i2s_register *) ioremap(I2S_BASE, I2S_SIZE); // cf noob.c to validate the cast Apr 27 12:18:01 So the question is, how do I add io opperation support on my yocto ? Apr 27 12:19:09 one header seems not included Apr 27 12:19:22 hey guys, I have a tool (U-Boot's binman: http://git.denx.de/?p=u-boot.git;a=blob;f=tools/binman/binman.py) that is failing to run because it's calling python2, but "python2" is not in the HOSTTOOLS, only "python", "python2.7" and "python3" are. http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/conf/bitbake.conf#n461 Is adding python2 to HOSTTOOLS the right approach? Apr 27 12:23:29 diego_: HOSTTOOLS_NON_FATAL, yeah Apr 27 12:25:52 diego_: thanks. Even if other "python" commands are in regular "HOSTTOOLS" var? Apr 27 12:27:37 stupid me, i meant rburton Apr 27 12:28:22 yeah because not everyone has a python2 binary Apr 27 12:28:52 python-pip (pip install software) ask me to update on the last yocto branch morty. Is it ok to update it ? Apr 27 12:29:08 Yeah I know I'm missing a header but what's weird is that compilation of the driver works on my computer Apr 27 12:29:29 that's why I'm wondering, wtf is different with yocto, and what am I missing? Apr 27 12:30:38 diego_: everyone should have a python2 binary but you can bet that some old distros don't :) Apr 27 12:31:05 diego_: oh actually if python2.7 is in the hosttools, then python2 should be safe Apr 27 12:34:05 hamdyaea : if you update to morty branch, be sure that everything you needed is also in morty. Apr 27 12:34:22 hamdyaea : don't forget that everything in your project should come from the same branch Apr 27 12:34:57 hamdyaea : but if something came from a older branch and doesn't exist in the morty branch, put it into a custom layer and pray that it would work Apr 27 12:36:08 YCN: each recipe builds in its own sysroot Apr 27 12:36:32 YCN: maybe that header was provided by other installed dependencies Apr 27 12:36:34 rburton: the list of py2 dependees ain't too bad - opkg-utils, kconfig-frontends, asciidoc, mc, parted Apr 27 12:37:03 rburton: I'll look at what is the situation with them now Apr 27 12:37:04 Yes I know that too ahah, I'm just wondering what's the packet that would give ioremap & co Apr 27 12:37:32 I've a file where I have a list with all available packets Apr 27 12:37:50 and when I grep "io" I don't really know which one I need... Apr 27 12:37:56 YCN: that0s kernel stuff, linux headers Apr 27 12:38:00 and I don't even know if they are the one Apr 27 12:38:30 yeah so they should come with the kernel I guess Apr 27 12:39:08 rburton: opkg-utils in particular we can and should switch to py3 Apr 27 12:39:44 YCN: are you building a kernel module?If not, add linux-libc-headers to DEPENDS Apr 27 12:41:05 yes I am ^^ Apr 27 12:41:41 ChrysD: when I install a software with pip install my_software. It install it and at the end it tells me that pip install must be update with the command : pip install --pip update ( I don't remember the exact words). If I do it, pip download and install itself his update. But my question is : The new version is compatible with yocto ? Maybe there is a reason that the yocto version of pip is not the last one.. Apr 27 12:42:11 YCN-: http://www.yoctoproject.org/docs/1.6.1/kernel-dev/kernel-dev.html#incorporating-out-of-tree-modules Apr 27 12:42:58 rburton: kanavin: but I assume that as long as "python2.7" is in HOSTTOOLS, "python2" should also be there, right? Apr 27 12:43:53 YCN-, please note the incipit Apr 27 12:44:03 "it is always preferable to work with sources integrated into the Linux kernel sources" Apr 27 12:45:06 diego_: I think so, yes, but generally if you want python 2, use just 'python' Apr 27 12:45:16 okay, so bicicly I should do as if my driver was mainline? Apr 27 12:45:56 write it as kernel patch Apr 27 12:46:31 and apply the patch for your MACHINE Apr 27 12:46:31 kanavin: is that a somehow official convertion (python = python2)? Apr 27 12:46:48 *convention Apr 27 12:46:59 hamdyaea : I don't know much about python + yocto. But updating pip isn't mandatory. If it works, let it works lol Apr 27 12:47:35 ChrysD: Yes maybe if it works like this I must not touch it Apr 27 12:48:43 diego_: yes, that is the official recommendation, and all distros except one use it Apr 27 12:48:54 @ant_work , thanks I will try to see this way, both MACHINE_EXTRA_RRECOMMENDS += "kernel-module-mymodule" and your solution didn't work, I'll try to do that as a patch Apr 27 12:49:20 (the one exception is arch linux I think, which we can probably ignore) Apr 27 12:49:51 diego_: I suggest you move your things to py3, or plan for it :) Apr 27 12:49:59 YCN-, MACHINE_EXTRA_RRECOMMENDS is for installing it once built ;) Apr 27 12:50:02 kanavin: it looks like "python" -> "python2" is a suggestion for the time being, but no guarantee, while "python2" should be the correct one https://www.python.org/dev/peps/pep-0394/ Apr 27 12:50:26 YCN-, to build a kernel module you have the two options: in the sources, extra Apr 27 12:50:30 Oh okay, well as you can see I'm not yet a Yocto expert ahah Apr 27 12:50:52 YCN-, th elinux-libc-headers are used to build stuff like mtd-utils Apr 27 12:51:14 or other userspace progs interfacing with kernel UAPI Apr 27 12:51:21 kanavin: "in preparation for an eventual change in the default version of Python, Python 2 only scripts should either be updated to be source compatible with Python 3 or else to use python2 in the shebang line" Apr 27 12:51:31 YCN-, it is really specific Apr 27 12:52:04 Okay so that's not what I want, since it's only about building a driver Apr 27 12:53:40 kanavin: so binman explicitly referring "python2" is the standard, and I feel adding it to HOSTTOOLS is reasonable (especially because of the "python" mess and the "python2.7" existance) Apr 27 12:54:36 diego_: sure, but the best is to port things to py3 :) Apr 27 12:56:36 hello, I have generated an SDK with cmake for cross-compilation... I am trying to use it to compile a simple program in Qt Creator for my board and get the following error: https://pastebin.com/Ny0BaGJk Apr 27 12:59:20 kanavin: sure, but I didn't write the tool myself :) I would be glad to do the port if only days were not 24 hours. Apr 27 13:01:28 diego_: eventually someone will have to do it :) Apr 27 13:02:37 I am using Krogoth community release for imx6 Apr 27 13:05:52 kanavin: initial python3 release 2008, python2.7 expected EOL 2020 http://legacy.python.org/dev/peps/pep-0373/ , so someone will likely go for it in a couple of years. Apr 27 13:08:05 eduardas_m : Did you follow every steps to compile using QtCreator ? Apr 27 13:16:19 ChrysD: I am not cross-compiling Qt creator itself... I am merely trying to use it to cross-compile a simple hello world cmake project for my board Apr 27 13:16:40 oh sorry Apr 27 13:16:45 misread Apr 27 13:17:13 qmake cross-compiling works however Apr 27 13:17:53 I also seem to set the corrct cmake tool from the sdk in my kit Apr 27 13:18:35 I also export the environment variables before launching qt creator as with doing qmake cross-compilation Apr 27 13:21:01 eduardas_m : I know i understand Apr 27 13:21:18 eduardas_m : I just say that qtcreator need to be configured Apr 27 13:21:42 eduardas_m : Be also aware that for version above 5.6 of Qt you should specify the Qtmkspec Apr 27 13:22:56 eduardas_m : If you put the correct Qt version / gcc / gdb / kit / Qtmkspecs should work Apr 27 13:23:39 ChrysD: this is not a Qt project although I am using Qt creator... though the kit is for Qt 5.6.2 Apr 27 13:24:20 qmake builds with the kit work, so gcc / gdb/ qmake locations are set correctly Apr 27 13:24:29 only cmake is giving me problems Apr 27 13:26:44 eduardas_m : don't you had some problems regarding path directories ? Apr 27 13:27:30 diego_: python should be python2, but some people (arch linux) set python as py3, which is why there's a python2 binary Apr 27 13:27:47 diego_: so using python2 is actually the preferred way because arch were stupid Apr 27 13:28:02 eduardas_m : sometimes it happens that when you put a library, or whatever in your project with a wrong path, it could happen... Like a space, or a bracket etc etc Apr 27 13:28:38 ChrysD: yeah, that happens sometimes... still checking Apr 27 13:29:25 eduardas_m : usually its the case, so double check. Could be very stupid things you know. Apr 27 13:30:55 ChrysD: this is the cmake error log: https://pastebin.com/CEaAGMS6 Apr 27 13:31:30 the path for the C compiler is correct though Apr 27 13:33:59 it is as if cmake from the SDK does not understand where the correct sysroot is though same sysroot in kit settings works well with qmake projects Apr 27 13:36:47 rburton: that's part of the truth. The article https://www.python.org/dev/peps/pep-0394/ has all the details. It's worth noting that "python" might move to "python3" in the future, so everything on "python2" should better be explicit about it from now on. Quoting the article "Future Changes to this Recommendation - It is anticipated that there will eventually come a time where the third party ecosystem surrounding Python 3 Apr 27 13:36:48 is sufficiently mature for this recommendation to be updated to suggest that the python symlink refer to python3 rather than python2 . " Apr 27 13:37:07 eduardas_m : yeah i checked, it's weird Apr 27 13:37:45 eduardas_m : Run Build Command:"/opt/fsl-imx-x11/4.1.15-2.0.1/sysroots/cortexa9hf-neon-poky-linux-gnueabi/usr/bin/make" "cmTC_63e32/fast" /opt/fsl-imx-x11/4.1.15-2.0.1/sysroots/cortexa9hf-neon-poky-linux-gnueabi/usr/bin/make: 1: /opt/fsl-imx-x11/4.1.15-2.0.1/sysroots/cortexa9hf-neon-poky-linux-gnueabi/usr/bin/make: Syntax error: word unexpected (expecting ")") Apr 27 13:38:58 eduardas_m : have you put somewhere the linux-oe-g++ ? Apr 27 13:39:16 ChrysD: I think it is related to this Qt Creator bug: https://bugreports.qt.io/browse/QTCREATORBUG-16155 Apr 27 13:39:42 ChrysD: yes, linux-oe-g++ is present in mkspec Apr 27 13:40:35 eduardas_m : yeah seems your probleù Apr 27 13:40:49 rburton: patch sent http://lists.openembedded.org/pipermail/openembedded-core/2017-April/136137.html Apr 27 13:41:34 eduardas_m : did you try ? Apr 27 13:48:10 kanavin: can't wait to see the de-py2 series :) Apr 27 13:52:47 rburton: I might wrap it up today even :D Apr 27 13:53:08 gasp Apr 27 13:59:20 kanavin: that's why you wanted me to port to py3, you're the Py3 paladin! Apr 27 13:59:40 diego_: I *love* removing stuff from oe-core Apr 27 13:59:53 diego_: py2 will be my biggest achievement yet in that department ;) Apr 27 14:00:28 diego_: you have a couple of years though still :) Apr 27 14:00:36 * rburton feels like the emperor admiring vader's work Apr 27 14:00:45 kanavin is strong in the ways of removing as much as possible from oe-core Apr 27 14:01:11 exceeeellent Apr 27 14:01:26 lol Apr 27 14:03:14 kanavin: I fully endorse your quest and write Python 3 code myself. It's just that sometimes you need to use software written by others ;) Apr 27 14:04:52 As i'm a newbie in all of that, what's bad about oe-core ? Because it's old and it's in a mess ? Apr 27 14:05:27 ChrysD: it needs to move with the times: new, useful recipes come, old, useless recipes go Apr 27 14:05:45 ChrysD: py2 is well on its way to the second category Apr 27 14:05:48 kanavin : Yeah I understand. Apr 27 14:06:20 kanavin : when you say oe-core, you mean all the basic package right ? Apr 27 14:07:16 ChrysD: I mean the recipes in this layer: http://git.openembedded.org/openembedded-core/about/ Apr 27 14:07:26 ChrysD: the bug report helped me... resolved by deleting default cmake configuration in kit and putting include (CMakeForceCompiler) in my CMakeLists.txt Apr 27 14:07:48 eduardas_m : Cool =) Apr 27 14:08:01 as stated with the bug report this has something to do with how either cmake or yocto sdk works and not qt creator Apr 27 14:08:34 ChrysD: have a read of https://www.openembedded.org/wiki/OpenEmbedded-Core Apr 27 14:08:36 can just hope that future yocto releases will not require such a workaround Apr 27 14:31:28 rburton: https://bugzilla.yoctoproject.org/show_bug.cgi?id=11181#c3 is the summary of what's left Apr 27 14:31:29 Bug 11181: enhancement, Medium+, 2.4 M1, alexander.kanavin, IN PROGRESS REVIEW , Remove Python 2 as a host tool or needing to be built for our core images Apr 27 15:41:40 kanavin: is scons actually being ported to py3? Apr 27 15:58:29 rburton: yes, we had this discussion :) Apr 27 15:59:59 oh missed that then Apr 27 16:00:08 genuinely surprised Apr 27 16:00:14 considering the faq goes on about py2.4 Apr 27 16:03:47 rburton: recent release notes all say 2.7 only Apr 27 16:03:59 (preparing for py3) Apr 27 17:05:59 rburton: if you look at scons repo, they had a bunch of py3 work that happened just this month Apr 27 17:45:48 kanavin: mind blown **** ENDING LOGGING AT Fri Apr 28 03:00:01 2017