**** BEGIN LOGGING AT Wed Feb 19 02:59:57 2020 Feb 19 08:27:46 kanavin_home: i can donate an ec2 instance for some hours or days in case of emergency. Feb 19 08:37:57 hello, I have a question about yocto and SDK. If I add a library ( called LIB for example ) to my image, it will be generated automaticaly with the SDK ? or I should add it manualy to SDK before bitbake it ? Feb 19 08:42:11 freeuser: if something is in the image, it is automatically also included in the sdk Feb 19 08:44:54 LetoThe2nd okey, than, if I want to use this SDK to compile a program which needs this LIB , should I add the include directorie path and the .LIB path to the configuration of my project ? Or just use the SDK ? I am confused about that because SDK contains all the headers and the libraries of LIB Feb 19 08:45:08 as I guess Feb 19 08:45:11 freeuser: "jsut use the sdk" Feb 19 08:45:33 that exactly what the environment setup script of the sdk is for, getting all the paths and flags right Feb 19 08:45:54 freeuser: and if that does not work, most likely your cmake/makefile/whatever buildsystem you're using is messing with the flags and you should fix this and not yocto :) Feb 19 08:46:02 your project on the other hand is supposed to properly handle such Feb 19 08:46:09 qschulz: dang you were faster Feb 19 08:46:30 freeuser: and, for reasons unknown, this is almost the thing that i'll be talking about tonight in the live coding session :) Feb 19 08:47:10 if i happen to have overtime i can even look at the sdk. yet there is already an episode that explains in-target vs. sdk vs. esdk, so be sure to watch it. Feb 19 08:48:07 LetoThe2nd qschulz okey thank you very much Feb 19 08:50:04 freeuser: https://twitter.com/TheYoctoJester/status/1229325758952345600 Feb 19 09:07:14 LetoThe2nd thanks Feb 19 09:08:16 qschulz as you have mentioned, when I try to use SDK withoud specifying the path of includes and libraries, CMake project can not find the headers I need Feb 19 09:13:25 New news from stackoverflow: simlink in eSDK sysroot points to a non existent path Feb 19 09:15:21 freeuser: the sdk comes with the env setup script for a reason. Feb 19 09:17:14 LetoThe2nd I have sourced the env setup script on the machine which holding the sdk. And I added than the path of the SDK without adding the includes and lib paths Feb 19 09:18:28 freeuser: i don't think thats right. Feb 19 09:18:48 freeuser: you have source it not somewhere, but in the very shell session that you want to build in. Feb 19 09:20:33 LetoThe2nd My SDK is located on my machine A. I use the path of this SDK on my machine B. So I need to source it on my machine B instead of A ? Feb 19 09:21:47 you have to source it in the exact session that you want to build in, no matter where it runs. Feb 19 09:22:10 and if you have diverging pathes to the install location, then you are doomed anyways. Feb 19 09:22:51 LetoThe2nd I will make a try Feb 19 09:22:59 in general i'd say, the sdk is meant to be install and used on the same instance (for instance being any kind of linux environment) Feb 19 09:43:32 New news from stackoverflow: modemmanager gsm registration timeout Feb 19 10:07:01 has anyone kept tabs on which companies have cancelled their participation to Embedded World ? From what i can tell, ARM, Digikey and Arrow have cancelled already. Feb 19 10:11:55 meego: AFAIK aldo ST, Xilinx and Atmel/Microchip Feb 19 10:12:01 *also Feb 19 10:13:39 New news from stackoverflow: My CMake project using SDK can't find boost library Feb 19 10:16:13 meego: https://www.cnx-software.com/2020/02/13/mwc-2020-cancelled-stmicro-withdraws-from-embedded-world-2020-due-to-covid-19/ Feb 19 10:24:29 is git://git.pokylinux.org/poky still supposed to be updated? Feb 19 10:27:11 halstead: hi, pulling from git://git.pokylinux.org/poky and git://git.yoctoproject.org/poky gives different master branch now, is something broken or is there some expected delay/caching involved? Feb 19 10:28:15 the yp.org one is 82 commits newer Feb 19 10:29:40 JaMa: the pokylinux.org domain is out of date and pointed at the wrong servers. I'll get that changed. Feb 19 10:45:51 meego: https://www.eetimes.eu/coronavirus-live-news-coverage/ Feb 19 10:47:28 mckoan: perfect link, thanks. So NPXP & Renesas too… :/ Feb 19 10:48:06 (typo: NPXP => NXP) Feb 19 10:53:15 halstead: thanks, I'll switch to new domain (I guess I've created this checkout very long time ago :)) Feb 19 11:15:31 I have strange error trying to build SDK: Exception: FileNotFoundError: [Errno 2] No such file or directory: '/disk2/build.24/tmp/work/tppg2-tps-linux-gnueabi/img-sp-tssz/1.0-r1/sdk/image/opt/tps/2.7-20200219/sysroots/x86_64-tpssdk-linux/usr/lib/locale Feb 19 12:25:57 Hi, my yocto user space program calls uint8_t* data = (uint8_t*)mmap((void*)0, desired_total_data_size, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB | MAP_HUGE_2MB, -1, 0); and I get a null pointer as valid memory address. Is this a known issue? AFAIK mmap should only return null pointers if I set the MAP_FIXED flag. Feb 19 12:28:12 Hi all, i'm stuck on samba config (Checking for system pyldb-util.cpython-37m-aarch64-linux-gnu (>=1.5.6 <=1.5.999) : not found) and I don't understand the issue :S any help ? :) Feb 19 12:50:31 fbre: perhaps OT Feb 19 12:55:53 its at least not exactly yocto inself. but if somebody happens to know :) Feb 19 12:57:21 I just thought it's a known issue within the yocto distro or something Feb 19 12:58:08 fbre: i highly doubt that its caused by the distro in itself, rather than maybe some kernel config or security measurement that you added. Feb 19 13:12:49 armpit: is there a non-zero chance of a patch being applied to 2.4-rocko or 2.3-pyro? Feb 19 13:30:00 RP: fixed that on target module issue. build 929 looks better. what (if any) were the known failures ? Feb 19 13:35:24 zeddii: no idea at this point Feb 19 13:58:12 zeddii: suspect we just need to retest Feb 19 13:58:48 I started a second build to see what I get without my changes. Feb 19 13:59:36 zeddii: that looks like master, couldn't you just compare with last nights build? Feb 19 13:59:45 zeddii: master should be ok? Feb 19 14:00:16 I had meant to push one fix, but yah, I see that it is just master now. I’ll stop that build and find one of the others to check. Feb 19 14:09:49 I can never figure out where to pull the settings out of those builds, is there a tab that I'm not clicking that I should to see the machine and other conf values ? or should I be cloning a config repo ? Feb 19 14:14:20 zeddii: look at the stdio log Feb 19 14:15:29 JPEW: that last perl determinism thing looks like a makefile race in the end :/ Feb 19 14:15:44 aha Feb 19 14:19:35 zeddii: I want to improve the autobuilder output but until the current day to day issues get sorted I don't have the bandwidth :/ Feb 19 14:37:09 RP: Ugh, perl Feb 19 14:39:24 JPEW: yes, I've filed it upstream Feb 19 14:39:37 JPEW: nice to understand it at least Feb 19 14:40:31 What is the correct ownership for installed files with in yocto recipes? 0.0 ? Feb 19 14:40:51 sveinse: usually, yes Feb 19 14:42:20 Is do_install running under a UID=0-ish environment? Thus allow me to use $USER as the UID to use? Feb 19 14:46:54 sveinse: its running under pseudo which fakes a root like environment Feb 19 14:54:43 RP: Do you have to do anything special to enable pseudo on install or is it enabled by default? If I run 'id' in do_install() I get "uid=0(root) gid=0(root) groups=0(root)" which is as expected, yet a "mkdir -p" on the next line produces dirs with my user uid and gid. Any ideas what I can do? Feb 19 14:57:31 What's that AUH mail on the ML? Feb 19 14:59:23 sveinse: in the do_install try a "ls -la" and see what that says? Feb 19 14:59:46 sveinse: obviously it can't really make things owned by root so you have to check under the fake environment Feb 19 15:00:08 qschulz: Automated Update Helper Feb 19 15:04:31 RP: yes, but what's the purpose of this mail? Feb 19 15:06:47 Is there anything to be done? Was anything done? E.g. is this something which updates recipes if upstream's been updated and test a build? In which case success are actual commits made and pushed somewhere? the fails have to be investigated yes, no? I understand this is useful to you/maintainers but it feels very "out-of-the-blue" and out of context for me, basic user :) Feb 19 15:08:20 RP: ah yes, of course, sorry I should of thouht of that. Thanks. Feb 19 15:13:45 RP: potentially stupid question, but can the testimage run be made to use slirp via some setting I'm not seeing ? my local multilib test image effort is failing at tap creation. Feb 19 15:14:13 * zeddii cracks open the class Feb 19 15:17:29 * zeddii finds TEST_RUNQEMUPARAMS Feb 19 15:18:11 qschulz: the listed maintainers get email with the output of the system which they're meant to do something with Feb 19 15:18:23 qschulz: that mailing list gets a summary of what happened Feb 19 15:20:00 RP: could a little bit more context be added at the top of the mail so that everyone has your answer? Also, why not post what the maintainers receive in that mail as well? Package upgrades could be a beginner task right? I guess some patches could be more or less straightforward? Feb 19 15:20:09 RP: thanks for the answer btw Feb 19 15:20:44 qschulz: yes we could add something to it. Patches welcome or a bug to do that(maybe with proposed text) Feb 19 15:20:59 crap. I can't run the multlib test on my builders. Feb 19 15:21:00 qschulz: typically we've not spammed the list with the patches but perhaps we should Feb 19 15:21:08 no X installed and there probably won't be. hmmm. Feb 19 15:21:41 * zeddii tries nographic on the qemu params Feb 19 15:21:43 zeddii: we don't use slirp by default since its a major pain for various reasons. People have tried to make it work, I'm unaware of anyone who succeeded Feb 19 15:21:55 I only use slirp :D Feb 19 15:22:01 * zeddii loathes tuns and taps Feb 19 15:22:28 we've gotten a long way using them on the autobuilder Feb 19 15:23:17 but yah. doesn't look like slirp will work for the run, it just failed to get an ip. that rules out my builders for now. I'll have to ponder. Feb 19 15:26:24 * RP gives marka a stern stare Feb 19 15:31:55 lol Feb 19 15:32:03 RP: is there any link to gstreamer ML/github for the setcap patch? (I see it's upstream-status = pending but missing a URL somewhere) Feb 19 15:32:04 we all give marka stern stares.. Feb 19 15:32:23 fray: he broke the build ;-) Feb 19 15:32:34 ok, and even more stern stare then Feb 19 15:32:37 qschulz: Pending means we need to submit so its not there Feb 19 15:33:19 RP: /me facepalms Feb 19 15:40:39 qschulz: I'd love someone with better meson knowledge or better upstream knowledge to submit it... Feb 19 15:40:56 live coding session about to start in 20 minutes! :-) Feb 19 15:40:57 RP: none here unfortunately :( Feb 19 15:43:09 qschulz: That patch is the sum of my meson experience ;-) Feb 19 15:45:34 (I meant, *I* don't have any knowledge in that) Feb 19 15:47:00 qschulz: right, I'm just meaning it isn't hard to pick up... Feb 19 15:48:37 Oh, I smell good stuff in Mark's mail. I'll read tomorrow morning with a fresh and rested brain. Feb 19 15:55:07 live coding session about to start in 5 minutes! :-) Feb 19 15:56:04 LetoThe2nd: https://www.twitch.tv/letoatreidesthe2nd/ Feb 19 15:56:11 qschulz: thx. Feb 19 15:56:15 What can I do if I get install error on a image. "Package packagegroup-product-base required crda, but none not the providers can be installed", yet crda is built and is available. How can I debug this? Feb 19 15:57:00 sveinse: there usually is a bit more messages i think Feb 19 15:57:52 qschulz: Only solution proposals removing my package groups (which I need) Feb 19 15:58:56 sveinse: check that packagegroup is not mixing recipe and binary package names. DEPENDS is for recipe names, RDEPENDS is for binary package names. Feb 19 15:58:59 sveinse: I've ran into this recently, the error messages from opkg aren't always very helpful. What distro and branch are you using? Feb 19 16:00:06 paulbarker: zeus, but custom distro overlay on poky Feb 19 16:00:42 If it's the same as I saw on thud with Arago distro, the root cause is wireless-regdb and wireless-regdb-static conflicting Feb 19 16:01:00 I assume there is a dependency missing or conflicting that I need to hunt down somehow Feb 19 16:01:08 paulbarker: right, I'll check that, thanks Feb 19 16:01:16 crda depends on wireless-regdb Feb 19 16:01:22 LetoThe2nd: o/ Feb 19 16:04:48 paulbarker: in my system wireless-redb RPROVIDES wireless-regdb-static it seems Feb 19 16:07:36 paulbarker: but you're right: I removed crdb from my top-level packagegroup and now it installs. In the resulting image I've got wireless-regdb-static, so something pulls that in. Thanks! Feb 19 16:09:17 I guess crda isn't needed any more with recent kernels but tbh I've not looked into it too deeply Feb 19 16:10:41 sveinse: looks like they still conflict on master: https://git.openembedded.org/openembedded-core/tree/meta/recipes-kernel/wireless-regdb/wireless-regdb_2019.06.03.bb#n28 Feb 19 16:11:54 fray: RP: unfortunately I deserved the stares Feb 19 16:12:37 I will try to make up for it Feb 19 16:27:54 marka: its all too easily done Feb 19 16:33:13 * zeddii hands marka a paper bag Feb 19 16:34:07 RP: looks like I misread that multilib failure. I didn't realize it was running more than one multlib test. bugger. I couldnt' even make the simple one work. Feb 19 16:35:02 zeddii: most of the builds run a succession of different tests Feb 19 16:35:18 zeddii: it should print the config for each one Feb 19 16:35:51 yah, I noticed that after doing the first one. the error implies it is the last one that blew up. which I think may be my old friend mips64 Feb 19 16:36:16 zeddii: thinking about it I think I can make this output easier to use Feb 19 16:37:02 ah yes. 6c is mips 64. I'll try that here, and then ping our mips64 friends if it isn't obvious. Feb 19 16:37:24 zeddii: the paper bag got wet and now I am trapped Feb 19 16:37:50 better than plastic, you'll survive (and the eco warriors won't come for you). Feb 19 16:43:20 LetoThe2nd: o/ Feb 19 16:44:09 LetoThe2nd: NOT FOR THE WEDDING ANNOUNCEMENT Feb 19 16:44:16 qschulz: LOL Feb 19 16:45:21 RP: I was looking at latest binutils patch from you on nativesdk relocation, this code has changed upstream Feb 19 16:46:56 RP: see https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=ef8f08ca13f6c111cc549a3e13be5c5e2d95ca82 Feb 19 16:48:37 RP: bug is here https://sourceware.org/bugzilla/show_bug.cgi?id=25477 Feb 19 16:48:38 Bug 25477: was not found. Feb 19 16:48:43 khem: hmm, interesting. I wonder if that helps us or not Feb 19 16:48:44 I wonder if we need your patch still Feb 19 16:49:23 khem: I suspect prefix won't relocate to where we need it :( Feb 19 16:50:15 prefix is from --sysroot I believe ? Feb 19 16:51:20 in that relocation patch hardcodes it to -DSYSCONFDIR which might break --sysroot logic Feb 19 16:51:21 zeddii: going forward, builds will be like https://autobuilder.yoctoproject.org/typhoon/#/builders/15/builds/1833 where the step1b log has the config at the start Feb 19 16:51:41 khem: --sysroot is not what we want here Feb 19 16:51:59 khem: we want the build sysroot, not the target Feb 19 16:52:00 right, my question is how it is supposed to work Feb 19 16:52:44 SRC_URI_append_class-nativesdk Feb 19 16:52:47 I see Feb 19 16:52:53 zeddii: http://git.yoctoproject.org/cgit.cgi/yocto-autobuilder-helper/commit/?id=89633facc462219020ae98f0c5ce9c2b39a29875 Feb 19 16:53:10 khem: right, I only changed the build we needed to change Feb 19 16:53:27 and nativesdk will always be relocated Feb 19 16:53:43 unless folks install it once and then copy the install tree around Feb 19 16:53:57 khem: if they do that other things will break Feb 19 16:54:08 yes Feb 19 16:54:23 khem: we really need to talk to the gcc people about what we need and how to do it all properly Feb 19 16:55:01 yeah perhaps GNU couldron attendence will help Feb 19 16:55:24 all GNU toolchain folks are there Feb 19 16:56:08 khem: hmm, paris in June Feb 19 16:59:41 mckoan: thanks for the input! Feb 19 17:04:19 i know the topic was a bit unconventional today, but hopefully it helps the newcomers :) Feb 19 17:09:44 LetoThe2nd: there's always someone who will find value in your articles/videos, don't worry if it didn't attract many people or make people interact on the chat. Feb 19 17:11:15 qschulz: hehe, it was more meant as a reason why i chose to talk about it :) Feb 19 17:11:49 qschulz: lately i conclude that most views accumulate on youtube anyways. i usually get 200 on a new video in the first week, or so. Feb 19 17:21:39 * RP spots how one of the mystery ab failures happens Feb 19 17:49:36 LetoThe2nd: YW Feb 19 18:10:04 RP: sent a binutils 2.34 update patch give it a shot when AB is free Feb 19 18:10:22 RP: I am running builds in parallel, its not DOA so far Feb 19 18:10:43 oh now I see a problem :) Feb 19 18:11:39 libtool: Version mismatch error. Feb 19 18:13:46 khem: I'll wait on the next version ;-) Feb 19 18:15:57 yes soonish Feb 19 18:16:13 there are so many ways we build binutils Feb 19 18:21:35 RP: I suppose there's nothing right now I need to look at? Feb 19 18:22:14 I can't do anything from work yet, and should be careful with doing yocto stuff at home as family is not keen on that :) Feb 19 18:23:07 RP: Would you mind doing a build of meta-mingw/master-next on the AB when it is convenient? Feb 19 18:32:26 JPEW, meta-mingw master-next build finished 40 minutes ago for that branch. do you need another build? Feb 19 18:33:27 JPEW, ah so you want the gcc changes Feb 19 18:34:54 kanavin_home: Nothing urgent, just the general bug backlog now.... Feb 19 18:35:22 JPEW: running Feb 19 18:35:36 armpit: that was earlier to test a fix I pushed there Feb 19 18:35:57 RP: Thanks! Feb 19 18:36:23 RP: What was the mystery failure? Feb 19 18:37:14 JPEW: the _signal_ one from selftest Feb 19 18:37:24 turned out to be our broken code :( Feb 19 18:37:32 * RP is in the process of deleting it Feb 19 18:37:57 kanavin_home and rburton would be proud Feb 19 18:48:01 * RP suspects he couldn't get away with deleting the svn fetcher Feb 19 18:51:16 RP: Sadly I've still got clients using that Feb 19 18:52:07 At least it's not p4 Feb 19 18:52:46 paulbarker: I wish the people use it would fix it and send patches and maybe improve the test suite Feb 19 18:56:43 RP: I'm a bit limited with what I can do with this one but I may be able to at least run the test suite in their context Feb 19 19:06:00 JPEW: Is https://bugzilla.yoctoproject.org/show_bug.cgi?id=13733 still an issue or not with the various patches? Feb 19 19:06:01 Bug 13733: normal, Medium+, 3.1 M3, JPEWhacker, NEW , Reproducibility issue in perl on ubuntu1604 Feb 19 19:14:26 RP: do you have a binutils build handy for x86_64 ? Feb 19 19:14:56 RP: That was the encode modules using host compiler to determine how to generate code Feb 19 19:15:47 I need to see output of -ld -m1 for x86_64 cross binutils on master if anyone has handy Feb 19 19:16:11 khem: yes Feb 19 19:16:11 RP: So I believe it's fixed. I believe all the perl reproducibility bugs I'm aware of have been fixed Feb 19 19:16:37 JPEW: that was my thought too. We could probably close that one then Feb 19 19:17:10 JPEW: thanks, I'll close? (or you can?) Feb 19 19:17:12 RP Will do Feb 19 19:17:16 RP: I am trying to get rid of patch for enabling pe targets so if you have ld built on master and can see what says with ld -m1 will help me Feb 19 19:18:59 khem: ./recipe-sysroot-native/usr/bin/x86_64-poky-linux/x86_64-poky-linux-ld: unrecognised emulation mode: 1 Feb 19 19:18:59 Supported emulations: elf_x86_64 elf32_x86_64 elf_i386 elf_iamcu elf_l1om elf_k1om i386pe i386pep Feb 19 19:22:03 RP: perfect thanks Feb 19 19:28:07 RP: sent V2 now Feb 19 19:51:40 RP: wait for v3 now I am seeing a target build fail Feb 19 19:53:12 Questions for anyone that wants to answer, what are some best practices for dealing with remote crashes of application software on embedded systems? Our product unfortunately gives 0 info not a core dump... Nothing so I'm looking for ideas on how this is typically handled, shipping binaries with symbols so a core can be recovered? We are using Feb 19 19:53:13 yocto not sure if that helps. Feb 19 19:56:18 is there a simple way to delete those bits of sstate cache that haven't been touched in a long time? Feb 19 19:56:23 trying to free up some space Feb 19 19:57:08 milloni: find -atime Feb 19 19:57:32 will removing random bits like that not break it though? Feb 19 19:57:48 no, if you are not running any builds at the same time Feb 19 19:57:55 ok, great Feb 19 19:57:58 thanks Feb 19 19:59:47 JBook_SE: reproduce the crash locally would be the first step Feb 19 20:02:50 JBook_SE: when reproducing the crash, you might want to change the configuration so that you get the info that you need Feb 19 20:02:58 (enable coredumps, debug symbols etc) Feb 19 20:03:43 i would say it's useful to have a "debug" variant of your product to use for stuff like this Feb 19 20:04:24 there are ways to do that in yocto Feb 19 20:05:17 are you using poky? i know poky has some DISTRO_FEATURES that might be relevant here Feb 19 20:07:16 Thanks for the input, we are trying to reproduce locally with a debug build but unfortunately it took something like 25 days of high activity to crash it the first time at the customer and we are struggling to reproduce Feb 19 20:07:48 I was thinking for the future how can this be avoided. we are using poky Feb 19 20:11:32 milloni the DISTRO_FEATURES you mention is there quick link to some documentation on these? Feb 19 20:12:19 JBook_SE: yeah if you google it it should come up with something Feb 19 20:12:41 JBook_SE: have a look at minicoreedumper, which is in meta-oe. Feb 19 20:12:42 in my experience customers are often bad at using yocto :) Feb 19 20:13:43 JBook_SE: i don't think theres a DISTRO_FEATURE around that you can use, you would have to introduce it yourself for your usecase Feb 19 20:15:30 minicoredumper looks very much like what we need Feb 19 20:15:48 milloni LetoThe2nd thanks for the input and help Feb 19 20:16:00 JBook_SE: have fun Feb 19 20:24:45 The number of weird races the autobuilder finds continues to amaze me :( Feb 19 20:25:21 RP: more quirks with running/stopping QEMU? Feb 19 20:25:45 tgamblin: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13803 Feb 19 20:25:45 Bug 13803: normal, Undecided, ---, unassigned, NEW , devtool setupClass file copying race Feb 19 20:27:00 Interesting! Feb 19 21:16:00 I'm working with NXP iMX8QXPMEK evaluation board. I downloaded bsp release L4.19.35_1.1.0_MX8QXP from following site: Feb 19 21:16:00 https://www.nxp.com/design/software/embedded-software/linux-software-and-development-tools/embedded-linux-for-i.mx-applications-processors:IMXLINUX?tab=Design_Tools_Tab Feb 19 21:16:01 This bsp release is for Yocto Project 2.7 (Warrior) Feb 19 21:16:01 I built yocto project for this bsp release. Then, I invoked following command to extract toolchain: Feb 19 21:16:02 DISTRO=fsl-imx-xwayland MACHINE=imx8qxpmek bitbake core-image-minimal -c populate_sdk Feb 19 21:16:02 A new folder is created in build/tmp/deploy/sdk Feb 19 21:16:03 Inside sdk folder, there is filename: fsl-imx-xwayland-glibc-x86_64-core-image-minimal-aarch64-toolchain-4.19-warrior.sh Feb 19 21:16:03 I copied this script to /opt folder. Then, I executed this script to install sdk. I chose to have sdk installed in build/mysdk folder. Inside mysdk folder, there is environment setup Feb 19 21:16:04 script: environment-setup-aarch64-poky-linux. I ran this environment setup script to setup sdk environment. What is the next step? The files that were compiled by yocto project, do I Feb 19 21:16:04 need to compile same set of files with sdk? If yes, how? Feb 19 21:16:05 Please provide detailed information in building linux image from sdk. Feb 19 21:16:06 I read through 'Yocto Project Application Development and the Extensible Software Development Kit(esDK)' but didn't find any information on compiling source code from sdk. I want to view same Feb 19 21:16:06 set of source code files that were compiled when I created the yocto project. Feb 19 21:25:42 jani191: usually you'd source that environment script and then use the compiler (CC), cflags and other settings to build your software Feb 19 21:26:48 RP: Where is the software? In sdk, where are the set of files that were compiled by yocto project? Feb 19 21:29:04 jani191: the output is in the sdk (e.g. the libraries and headers) but not the original source, that would be in the original build Feb 19 21:33:12 RP: What is the use of sdk? Feb 19 21:34:19 jani191: The SDK is useful if you want to build software outside of Yocto. For example, we compile our proprietary applications with the SDK then copy them to the device for development Feb 19 21:36:59 RP: this patch has been dropped many times, but i have never got any feedback http://lists.openembedded.org/pipermail/openembedded-core/2020-February/293137.html Feb 19 21:39:05 I booted my target board with embedded Linux image built from yocto project. I need to step through USB host source code in embedded Linux kernel. Do I use sdk to create my development and debug environment? Feb 19 21:47:09 kanavin_home: its on my "not quite convinced its right or wrong" list Feb 19 21:47:41 kanavin_home: I think it depends how we define the image and I'm not sure we clearly did that Feb 19 21:47:47 JPEW: >> 'then copy them to the device for development' Do you mean you integrate your proprietary applications with the Yocto Project and rebuild Linux image from Yocto Project for testing? Feb 19 21:53:54 RP: not sure I follow you, but are you seeking something like three ptest images, one with only fast tests, another with fast+slow, and a third with the full set? Feb 19 21:54:08 (fast+slow+ptest-pkgs) Feb 19 21:55:04 because otherwise I'm not sure what the argument against the patch is. ptest-pkgs pulls in bash-ptests which is otherwise banned for being unstable, and it is entirely coincidental it does not pull in something from the blacklist that hangs Feb 19 21:56:54 kanavin_home: we have multiple conflicting requirements for that image. It was partly there to illustrate the ptest image feature but then I broke it with the fast/slow thing Feb 19 21:57:21 kanavin_home: Your patch is probably the right thing to do, I'm just not 100% sure Feb 19 22:02:38 I am fully convinced that ptest-pkgs is actually harmful, as you never know what you end up with in the image and how long ptests will take :) explicit lists are the way to go Feb 19 22:04:28 jani191: Yes, our nightly builds and release builds are built completely in Yocto Feb 19 22:05:22 jani191: The SDKs are primarily used so that we don't need all developers to build up the complete image when all they care about is a single application Feb 19 22:05:39 jani191: Many can't anyway because they use Windows Feb 19 22:07:52 JPEW: I just want to make sure I understand. When you compile your proprietary application with sdk, you cannot test it unless you integrate and build it with yocto project? Feb 19 22:09:04 jani191: No. The application built with the SDK can be copied over to the target and run as you would any other application Feb 19 22:09:19 jani191: That's sort of the purpose of the SDK :) Feb 19 22:10:56 jani191: It's just that the (traditional) SDK can't build up a whole image, and when it comes time to release, attempting to shove together an application built with the SDK and an image built with Yocto is complicated (beleive me, I've tried :); it's easier to build the application in Yocto in the first place Feb 19 22:12:42 jani191: But, it also depends on your use cases; one of the great things about Yocto is that it can support a lot of different ways of building up embedded systems Feb 19 22:14:11 JPEW: >> 'copied over to the target and run as you would any other application' so application built in sdk can run in target without uboot, kernel, and file system? Feb 19 22:15:59 kanavin_home: well, yes, but it should match the ptests to the contents of your image Feb 19 22:18:25 i currently have a need to make fit images differently from how yocto does it now. i need to do it as part of image generation and not as a task in the kernel recipe. what is the right way to depend on the kernel from a recipe? DEPENDS = "kernel-vmlinux" ? Feb 19 22:20:17 mischief: depends which bit of the kernel you want to depend upon really Feb 19 22:20:33 DEPENDS += "virtual/kernel" is one way Feb 19 22:21:31 ah, right. we have PREFERRED_PROVIDER_virtual/kernel set to our own kernel recipe. Feb 19 22:21:51 i need to make a fit image but i can't use kernel-fitimage.bbclass Feb 19 22:22:24 https://autobuilder.yoctoproject.org/typhoon/#/builders/75/builds/1591/steps/8/logs/warnings - /me wonders what will break next :( Feb 19 22:22:34 the fit image i need to make is tied directly to the root filesystem, so i think it is appropriate to implement it as an image class - does that seem right? Feb 19 22:22:42 JPEW: that build was green btw Feb 19 22:23:18 mischief: that would seem reasonable (as an extra image type) Feb 19 22:24:17 ok. we need this for dm-verity btw, where the root hash of the fs is inserted into the fit. yocto does not seem to cater to this case very well currently. Feb 19 22:26:03 * RP files a bug for the warning, its a race Feb 19 22:26:32 mischief: I'mnot very happy with the fit support, not least as there are no tests Feb 19 22:29:16 kanavin_home: https://autobuilder.yoctoproject.org/typhoon/#/builders/89/builds/1595 Feb 19 22:29:44 JPEW: ^^^ Feb 19 22:29:58 * RP wonders how much of -next needs to drop because of that :( Feb 19 22:30:29 jani191: "so application built in sdk can run in target without uboot, kernel, and file system?" <-- Not typically Feb 19 22:31:59 jani191: "so application built in sdk can run in target without uboot, kernel, and file system?" <-- Not typically+busybox+....) Feb 19 22:32:09 oops: Feb 19 22:32:16 RP probably just the wayland meson conversion patch Feb 19 22:33:16 jani191: your conversation with JPEW suggests that you'd need to deploy your app on top of core-image-minimal (uboot+linux-yocto+busybox+...) Feb 19 22:34:03 jani191: it's possible to build a 'bare-metal' system using yocto but that's not the typical workflow. Feb 19 22:34:43 kanavin_home: thanks Feb 19 22:34:55 jani191: see: https://www.yoctoproject.org/docs/2.7/sdk-manual/sdk-manual.html Feb 19 22:36:30 vmeson: >> you'd need to deploy your app on top of core-image-minimal (uboot+linux-yocto+busybox+...) but the sdk that I setup doesn't have uboot + Linux + yocto + busybox? All it has is libraries and headers? Feb 19 22:38:07 vmeson: core-image-minimal is in yocto. sdk doesn't have it? Feb 19 22:40:23 jani191: right, so you need to get the steps to boot core-image-minial from NXP if you don't have them already. Feb 19 22:41:18 vmeson: I created core-image-minimal from yocto and booted target from sdk card. Feb 19 22:42:40 vmeson: My question is that I setup sdk by extracting toolchain from yocto project. What does this sdk contain? Feb 19 22:42:54 jani191: okay (I'm not actually sure what an "sdk card" is... ) Feb 19 22:43:07 vemson: soryy sd card Feb 19 22:43:09 RP: finally sent v3, which should work, please schedule that one for binutils Feb 19 22:43:15 vmeson: sorry sd card Feb 19 22:43:40 jani191: the sdk is a -software development kit- so it contain the compiler and various libraries and header files that you can link your application against. Feb 19 22:43:55 jani191: ah ha! -- that's a bad typo! :) Feb 19 22:45:22 vmeson: so if I build 'hello world' application in sdk. The built binary image will only contain 'hello world' ? Feb 19 22:46:19 vmeson: The build binary image won't compile any other packages, such as uboot, kernel, and file system? Feb 19 22:47:02 jani191: correct. Feb 19 22:47:08 vemson: And I can run 'hello world' application in my target board? Feb 19 22:47:19 jani191: yes. Feb 19 22:47:49 vmeson: what will be the file extension of 'hello world' application? Feb 19 22:48:19 khem: https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/727 Feb 19 22:48:38 halstead: autobuilder is getting quite the workout ;-) Feb 19 22:48:55 jani191: Of course you have to get the app to the target somehow... scp,or mount the SD card, or use rpm/ipk. there are many ways to do it. Feb 19 22:50:15 RP: thanks I will monitor it Feb 19 22:50:29 jani191: it depends on what you tell the compiler to call it. The -o flags takes any name! :) I think you need to read some docs and maybe watch some introductory videos to learn a bit about Yocto. Feb 19 22:51:48 vmeson: ok. So applications built in sdk run stand alone in target because sdk doesn't compile uboot, kernel, and file system packages? Feb 19 22:51:48 jani191: people seem to like the "Live Coding with Yocto Project #1: download and first build" series: https://www.youtube.com/watch?v=EfKLrSxA_H8 Feb 19 22:52:16 I haven't watched it since I've been using Yocto and doing embedded development for a while. Feb 19 22:53:52 vemson: Your help is much appreciated. Feb 19 22:53:56 jani191: spend a bit of time reading docs, watching these videos, do some tests and come back later this week. okay? Feb 19 22:54:16 vmeson: ok. One more question Feb 19 22:54:28 jani191: sure, it's a big learning curve. We can help a bit but there's no subsitute for hands on experimentation. Feb 19 22:54:47 jani191: ok, but I'm going to have to charge you double for that one! :) Feb 19 22:56:14 vmeson: Applications built with sdk must run stand alone in target board because uboot, file system, and kernel aren't built in sdk? Feb 19 22:57:15 jani191: your question is too vague. If you ask if hello-world runs on top of core-image-minimal, then I can say yes but... Feb 19 22:58:14 vmeson: How can hello-world run on top of core-image-minimal when sdk doesn't build core-image-minimal? Feb 19 22:58:22 an application _could_ link agains other libraries that you also need to bring to the target. Try building core-image-minimal for qemux86-64 and then use 'runqemu'. Feb 19 22:58:27 you'll learn loads! Feb 19 22:59:27 jani191: https://www.yoctoproject.org/docs/2.7/brief-yoctoprojectqs/brief-yoctoprojectqs.html Feb 19 22:59:54 vmeson: >> Try building core-image-minimal for qemux86-64 and then use 'runqemu'. build this from sdk? Feb 19 23:00:56 jani191: no, just follow the steps in the 'Yocto Project Quick Build' document that I just linked above. Feb 19 23:01:27 jani191: then you can take what you learn from there and figure out the sdk. okay? Feb 19 23:03:10 vmeson: ok but I already built yocto project for nxp board and I'm not getting the big picture on sdk. Feb 19 23:08:43 jani191: maybe some (Wind River specific) docs will help you get the big picture: https://docs.windriver.com/bundle/Wind_River_Linux_User_Space_Developers_Guide_CD/page/mmo1403548690067.html Feb 19 23:08:58 * vmeson wraps up for the day. Feb 19 23:10:33 jani191: think of the sdk as a standalone toolchain you could use for development, or you could use the full build environment instead. Some people need one, some people need the other Feb 19 23:15:32 RP: By full build environment, I believe you mean yocto project. Yocto project contains USB System and USB drivers in Linux kernel. I have setup sdk from yocto project. If I create USB application from sdk and load it in my target board, I can't test it because I don't have the kernel? Kernel is in yocto build. It's not in my USB application Feb 19 23:15:32 I build from sdk? Feb 19 23:17:35 I'm not getting the point of sdk because the stand alone application created from sdk can't be tested because sdk doesn't create the framework or lower layers of software? Feb 19 23:18:02 jani191: presumably you have a kernel and rootfs image for your board. The SDK will contain some development headers. Whether there are enough headers there to do USB kernel dev work I'm not sure Feb 19 23:19:02 RP: ok. Thank you! Feb 19 23:19:16 vmeson: Thank you! Feb 19 23:20:07 JPEW: and anyone else that helped me with SDK questions. Thank you! I appreciate the help. Feb 19 23:57:16 zeddii: we need to backport https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/patch/?id=0ada120c883d4f1f6aafd01cf0fbb10d8bbba015 for perf to build with latest binutils Feb 19 23:57:56 zeddii: I am carrrying https://github.com/YoeDistro/openembedded-core/commit/9c93c1266feee08afd11ddf0ed0601645dc347da temporarily Feb 20 00:07:52 Khem, too much tea for you Feb 20 00:08:19 heh Feb 20 00:38:12 Hello, I have a set of recipes I want to each build multiple packages, one per 'username,' and I want to define the usernames in a common list ${MY_USERNAME_LIST} included in each recipe. Feb 20 00:38:21 I can split and loop ${MY_USERNAME_LIST} in to ${MY_USERNAME} inside do_install(), but is there a good way I can dynamically create the appropriate FILES_${MY_USERNAME} = "/home/${MY_USERNAME}" and pkg_postinst_${MY_USERNAME}_append() and pkg_prerm_${MY_USERNAME}_append() functions? Is this an appropriate idea? Feb 20 00:40:07 khem: ack’d. I’m finishing some testing and can add it shortly. Feb 20 01:38:07 I'm trying to replace a "defconfig" file the meta-ti layer with one in my own meta layer. I've prepended "${THISDIR}/${PN}:" to FILESEXTRAPATHS, yet it's not working. Feb 20 01:38:40 I've checked that FILESEXTRAPATHS for the kernel does have my meta layer first, the path is correct, there is a file named "defconfig" in the named directory, etc. Feb 20 01:40:00 is there a debug tool to see in more detail how "file://defconfig" is resolved and why the first matching file in FILESEXTRAPATHS is not the one used? Feb 20 01:43:49 xyzzy42: most probably because machine-overrides take precedence. put your defconfig in the ${PN}// directory in your layer and see if that helps. don't change FILESEXTRAPATHS Feb 20 01:47:11 denix, The machine-overrides directory is probably one of the directories listed in FILESPATH? I do see that there is a dir under meta-ti that exists in FILESPATHS. Feb 20 01:56:50 denix: Thanks, that got me on the right tack. I did need to modify FILESEXTRAPATHS too and also place the file in a machine override directory in my layer Feb 20 01:57:48 The problem appears to be FILESEXTRAPATHS of dir1:dir2 with machine mach1 results in a final search order of dir1/mach1:dir2/mach1:dir1:dir2 Feb 20 01:58:24 So a file in dir2/mach1 takes precedence over dir1, even though dir1 is before dir2 in the path search order. Feb 20 02:00:57 Hi all, I'm banging my head against a wall trying to have a header file appear in my generated SDK Feb 20 02:00:57 inserting the missing header to the SDK) Feb 20 02:06:48 zeddii: thanks, this should go along with https://patchwork.openembedded.org/patch/170267/ Feb 20 02:10:39 xyzzy42: your FILESEXTRAPATHS should not have machine directories listed - those are standard OVERRIDES and those are expanded automatically Feb 20 02:11:37 denix: It does not. But FILESPATH does have them, and it appears that's what the final search order is. Feb 20 02:14:26 xyzzy42: the issue is that if underlying layer already has machine-override files (e.g. dir1/mach), then your additional layer won't be able to just use files in dir1 or dir2 - the easiest way is to place your new file under dir2/mach and point FILESEXTRAPATHS to dir2 Feb 20 02:16:22 xyzzy42: correct, you don't list dirs in FILESEXTRAPATHS - all the OVERRIDES will be automatically expanded into the final FILESPATH list **** ENDING LOGGING AT Thu Feb 20 02:59:57 2020