**** BEGIN LOGGING AT Fri Dec 28 02:59:58 2018 **** BEGIN LOGGING AT Fri Dec 28 03:14:53 2018 **** BEGIN LOGGING AT Fri Dec 28 05:26:53 2018 **** BEGIN LOGGING AT Fri Dec 28 05:34:10 2018 Dec 28 08:45:39 New news from stackoverflow: Yocto - Linux Image Generation - Remove qemu Support Dec 28 09:20:18 khem: thank you for explanation (luajit) Dec 28 14:31:01 is there a package that contains bluetooth utilities like hciconfig, hcitool, etc? Dec 28 14:43:39 nm, hciconfig is already present. Dec 28 16:04:17 RP: I am seeing a problem with SDK generated with master where it cant find some of target c++ headers see example https://8n1.org/14272/ade1 Dec 28 16:05:22 here are logs https://8n1.org/14273/9703 Dec 28 16:06:23 somehow its not looking at right dirs when it comes to to look for include and include-fixed dirs, it somehow looks into nativesdk sysroot Dec 28 16:20:06 khem: the nativesdk sysroot ones are a red herring, that is just due to the compilers location Dec 28 16:20:44 khem: why doesn't it find it in /opt/yoe/2.6/sysroots/riscv64-yoe-linux/usr/include/c++/8.2.0 ? Dec 28 16:55:44 RP: this is what native compiler has for include search paths https://8n1.org/14274/f997 Dec 28 16:58:30 RP: let me see if I get same issue on x86 Dec 28 17:28:24 is there any reason why useradd has been patched to change the meaning of the existing "-P" option instead of adding a new custom option? Dec 28 17:32:57 dkc: OE implements its own useradd utility Dec 28 17:33:14 which is a python script Dec 28 17:33:38 which is a wrapper over a commonly available tool Dec 28 17:35:11 I mean, if OE makes me type "useradd" in EXTRA_USERS_PARAMS, I expect the command to behave like the one on my machine, seeing "-P" followed by something that doesn't look like a directory is very confusing Dec 28 17:37:19 and documentation is scarce on this point, so I had to dig to find out the patch responsible for that: https://github.com/openembedded/openembedded-core/blob/ae12c5f86601a81f4208fd371ce8803464aedaa0/meta/recipes-extended/shadow/files/allow-for-setting-password-in-clear-text.patch Dec 28 17:37:29 thats reasonable expectation, although this is a cross tool unlike usual useradd Dec 28 17:40:54 that's a cross tool we are suppose to call if we want to create users, so switching options like that is imho not a sane thing to do Dec 28 17:42:18 RP: it works ok for x86_64 SDK https://8n1.org/14275/38c3 Dec 28 17:42:38 RP: so something specific to riscv in gcc probably multilib Dec 28 17:42:54 anyway, this patch has been in oe-core for so long that changing it is not very feasible, just wanted to point that out Dec 28 17:51:27 it's definitely not ideal, but as you say, a bit late now, but gets the job done. god, that statement applies to a lot of things actually :) Dec 28 17:51:49 RP: on x86_64 you see /opt/yoe/2.6/sysroots/core2-64-yoe-linux/usr/include/c++/8.2.0/x86_64-yoe-linux in search path but for riscv you dont see /opt/yoe/2.6/sysroots/core2-64-yoe-linux/usr/include/c++/8.2.0/riscv64-yoe-linux Dec 28 17:52:27 dkc, kergoth law of karma :) Dec 28 18:21:12 Hello, I am looking for ideas on how I might be able to get a newer version of Python into my build. Thud provides 3.5.6. My application needs >3.6, but I'd prefer to use 3.7. I have successfully built with the patches from patchwork on the specified commit, but I don't currently have the experience necessary to rebase those patches on the thud branch. Are there any workarounds or methods I could use to include a newer python at Dec 28 18:22:09 would it be possible for me to integrate a python build from the patched commit into a build based on thud? Dec 28 18:42:00 dresserd: there are patches for upgrading python to 3.7 on mailing lists Dec 28 18:42:15 you might want to try one of the latest revs Dec 28 18:44:31 see https://patchwork.openembedded.org/patch/156060/ Dec 28 18:44:36 e.g. Dec 28 19:29:48 khem: Thanks, I successfully built using those patches, but they are based on an older commit. Could I build Python from that commit and then somehow integrate it into a build based on the thud branch? Dec 28 19:30:19 I think so Dec 28 19:31:07 but I think the patches are not upstream yet, I forget whats pending, but you might want to take the latest rev of the patch and then watchout for it getting integrated into master Dec 28 19:31:18 and maybe if you can help making sure it works for you Dec 28 19:33:57 Thanks, I'll try it. Dec 28 20:05:48 hey guys ive been out for a while and trying to test out some patches, master is breaking for me (without any of my patches) and I just want to know if its a known issue Dec 28 20:06:08 libpcap cant find header files Dec 28 20:06:11 fatal error: linux/types.h: No such file or directory Dec 28 20:08:59 nvm my local.conf was screwing with e Dec 28 20:09:01 me Dec 28 20:10:37 khem: dresserd there was a cross compile / host contamination issue with python 3.7 IIRC Dec 28 20:16:15 aehs29: Thanks for the heads up. I'd be willing to help test any fixes or patches. Unfortunately, I don't have the experience yet to address those kinds of issues on my own. Is anyone actively working on Python 3.7 support. I'd expect Python to be widely used. Dec 28 20:24:28 dresserd: it is widely used, there are several of us who are usually involved in python issues, but the latest patches for 3.7 were provided by Jens Reshack, I'm currently not aware of the status of his work on it Dec 28 22:06:36 hi Dec 28 22:06:46 Does smart packagemanage not exist in sumo? Dec 28 22:18:38 NeilS: No, you should be able to use dnf instead Dec 28 22:20:13 So would i be able to update existing devices using smart and then it just switched over to dnf and just works? Dec 28 22:37:06 khem: I think I saw something like this for AVR, its to do with gcc configuration for the arch :/ Dec 28 23:01:44 khem: I see you sent a patch :) Dec 28 23:02:22 kergoth: we can remove Feeder() but it turns out that just chunking the list of things to parse and sharing amongst the threads is faster in the corner cases... Dec 28 23:03:30 kergoth: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=dfcad330a2d3b6eb039c0770614eb0ed90808a83 is 0.2 in 2s faster for parsing a single recipe for example and 22s in 190s for oe-core recipes Dec 28 23:06:03 ah, nice. i can't help but wonder if multiprocessing has come far enough to just rework using futures or a pool map rather than job and result distribution via queues Dec 28 23:12:53 kergoth: I suspect it could be made to work Dec 28 23:59:53 Reboots complete and AB is ready. Dec 29 00:19:59 RP: yes, fixed it. I also see that we have three patches doing same things for different arches, I have squashed all three into one for gcc 9 **** BEGIN LOGGING AT Sat Dec 29 02:54:28 2018 **** ENDING LOGGING AT Sat Dec 29 02:59:58 2018