**** BEGIN LOGGING AT Thu Feb 20 02:59:57 2020 Feb 20 06:57:47 Hi all, is there a Xenomai Mercury and/or Cobalt layer for raspberrypi3-64 for kernel 4.19 or better? I'm trying to cobble my own together but would love to know if there's already one out there. Feb 20 07:00:39 So far I've found this: https://github.com/s-vincent/meta-raspberrypi-rt-sv which I'm using as a starting point Feb 20 07:26:12 ningauble: If I look at layers.openembedded.org I find: https://layers.openembedded.org/layerindex/branch/master/layer/meta-xenomai/ Feb 20 07:31:47 ningauble: this is the very best place to get started with xenomai: https://gitlab.denx.de/Xenomai/xenomai-images/ Feb 20 07:32:59 erbo: many thanks; that tree appears to be stuck back at 4.9 while I'm looking for 4.19+... Maybe I can adapt it as well. Feb 20 07:34:25 LetoThe2nd: thanks also, I'll see if I can find what I need in there too Feb 20 07:34:53 good luck. i failed with that... no free beer in there. Feb 20 07:35:34 PREEMPT_RT is easy enough, but for some reason Xenomai via Yocto eludes me Feb 20 07:36:57 ningauble: in the repo given are recipes etc. for xenomai on 4.19. you only have to add in a raspi kernel config, then you should be good to go. Feb 20 07:39:39 Hmm... I see only 4.9.45 but I'll dig deeper in the morning. Again thanks for the assist! Feb 20 07:40:15 ningauble: https://gitlab.denx.de/Xenomai/xenomai-images/blob/master/recipes-kernel/linux/linux-xenomai_4.19.bb Feb 20 07:40:47 Oh, right on..! Thanks Feb 20 07:42:13 I had confused that repo with erbo's link to OE; sure enough that'll do Feb 20 08:32:39 anybody familiar with cve-check? How can I get a log that only shows unpatched ones? Feb 20 08:55:46 also about cve-check, bitbake give many error that it cannot compare version when there is a "+"-sign in version string (and there is many such packages), but still in final log those are marked as "patched"? Feb 20 09:46:18 stuom1: master, zeus or some other branch? cve-check does throw warnings of all unpatched CVE to bitbake output. Then both patched and unpatched are listed in tmp/deploy/cve/ for recipes and images. image output includes all development tools which makes it for me a bit useless. sadly whitelisted CVEs are not listed in the reports. Have not seen the + issue myself, but feels like a bug. Feb 20 09:53:23 Hello, afteradding Boost library into my SDK in Yocto project, I want to know if there is a hint or something that let me know which compiler is used to build this library into my project Feb 20 09:53:43 gaston53: can you rephrase? Feb 20 09:55:03 I am using Yocto project. I bitbake the SDK toolchain. I added the " boost " library into this toolchain. I don't know which compiler is used in order to build this library into the toolchain Feb 20 09:55:50 gaston53: i got the first two parts. but the last part doesn't make sense to me. Feb 20 09:56:24 gaston53: are you asking which compiler built the boost libraries? Feb 20 09:56:24 I thought that the boost libraries name will be like this : " boost_lib_atomic_gcc_mt " or something like this, here I can find that the compiler is " gcc " Feb 20 09:57:25 libboost_atomic is only what I find in the name of the lib Feb 20 09:57:46 gaston53: what is it that you *ACTUALLY* want to do? Feb 20 09:58:25 because this sounds massively like an XY question. you want to do X, and are stuck. you think that Y is a way to solve it. you are stuck on Y again, and thats what you ask us. please ask about X directly. Feb 20 09:59:47 In a CMake project Debug, it tells me that " boost_COMPILER = "-gcc74" (guessed) Feb 20 10:00:10 I want to add a variable in this project and specify the real compiler Feb 20 10:00:21 I am confused about this " guessed " Feb 20 10:01:01 Hi all, hopefully a quick question. I needed to tweak sysctl.conf. I use procps within my image, and added a bbappend to procps to refer to my sysctl.conf Feb 20 10:01:11 nailing down the compiler in the project is bad Feb 20 10:01:28 However it seems another package must override the procps sysctl.conf file as the one within procps does not seem to eventually end up in my image. Feb 20 10:01:45 Am I fighting multiple recipes supplying sysctl.conf somehow? Feb 20 10:01:49 gaston53: why do you even care about the specific compiler? i mean, cmake can find and use boost without firther ado. Feb 20 10:02:12 gaston53: I think we're in the XYZ situation, where you've now given us Y and Z, please give us X :D What exactly are you trying to achieve, like the actual problem. Why do you care to know the compiler? Feb 20 10:02:26 qschulz: ++ Feb 20 10:02:43 LetoThe2nd: you beat me to it that time :) Feb 20 10:03:08 qschulz: better this than proposing to you, don't you agree? Feb 20 10:03:44 LetoThe2nd qschulz Beacause I have multiple boost libraries with the same version on my machine which are build differently Feb 20 10:03:44 mcfrisk: im using thud Feb 20 10:04:04 I will delete them than Feb 20 10:04:12 gaston53: but hopefully only ONE in the sdk. Feb 20 10:04:38 LetoThe2nd: depends, if you're offering unlimited lifetime beer supply, we might find some common ground ;) Feb 20 10:04:49 gaston53: and if your crossbuild refers to something on the dev host, you're deeper in trouble than you even realize Feb 20 10:05:04 qschulz: i though you would bring the beer supply? Feb 20 10:05:42 LetoThe2nd I am hating my life on this project anyway Feb 20 10:05:58 LetoThe2nd: I drink mostly IPAs, so you'll be sad if I do. Let's call this thing off. Feb 20 10:06:19 stuom1: you might want to backport a lot of cve-check related changes from master branch. I did this also for sumo.. Feb 20 10:06:39 gaston53: to be honest, my impression is that because you are clinging to wrong pre-assumptions coming from non-cross development. Feb 20 10:06:58 qschulz: hm. yeah. "sorry darling, it couldn't ever have worked!" Feb 20 10:07:17 LetoThe2nd: let's stay friends, better for both of us. Feb 20 10:07:31 qschulz: *nods and sobs* Feb 20 10:07:42 LetoThe2nd you are right .. I guess .. Feb 20 10:07:58 mcfrisk: ok, I will try Feb 20 10:08:22 gaston53: and to be even more honest, i think all that dance arond the SDK is causing a lot of the troubles. Feb 20 10:08:29 LetoThe2nd: there there Feb 20 10:08:56 gaston53: why don't you "just" take your build, devtool add whatever you proejct is and see what happends? Feb 20 10:11:50 gaston53: i even walked through the process in a, however introductory fashion just yesterday... https://youtu.be/NmPta5w6P70 Feb 20 10:14:04 Hmm. OK. Sorted my own problem. Had sysctl.conf in a ${PN} subdir and not a files subdir. Seems like it didn't get packaged from there? Didn't think the main recipe cared though... Feb 20 10:14:58 LetoThe2nd cross compiling with SDK is not my problem, I have succeded to cross compile a c++ program using the SDK toolchain and executed it on remote platform, I have created a makefile and mentioned what I need from the SDK ( compiler ) and Boost library ( which is the most complicated library I have ever seen ) and all run well Feb 20 10:15:17 JoeR: the search path for things the recipe refers to is basically either a "files" subdirectrory or "${PN}" subdirectory. Feb 20 10:15:45 JoeR: bitbake -e your thing and look for FILEEXTRA-something to find out more. Feb 20 10:15:56 LetoThe2nd But I am facing a lot of problem trying to use all these in VisualStudio with the details of CMake project Feb 20 10:16:33 gaston53: see, *NOW* we have finally reached X. Feb 20 10:16:55 LetoThe2nd my objective is to set a suitable configuration CMake project which will make a program run on multiple platforms architecture Feb 20 10:16:58 Yeah, that's what I thought. I didn't think it cared, I did the FILESEXTRAPATHS_prepend of ${THISDIR}/${PN} Feb 20 10:17:11 using SDK , boost , and other tools Feb 20 10:17:16 gaston53: because the *REAL* question is, "how do i make the sdk and cmake play nice with VS" Feb 20 10:17:36 And had the file in a procps subdir of procps. bitbake was happy to build that. But I never got my file in the rpm. Feb 20 10:17:39 LetoThe2nd That's it Feb 20 10:17:52 Changing to a files subdir and it all just worked. Feb 20 10:18:06 gaston53: please mention this very early the next time, because most people here do not care about VS. i do not, too. Feb 20 10:18:47 JoeR: FILESPATH to be checked with bitbake -e, then you'll understand much more (or have a look at WORKDIR/temp/log.do_fetch (I think? or unpack)) There you have the order. I've been bitten by this one thing before as well :) Feb 20 10:18:50 gaston53: as long as the build process in itself works, we are happy. don't get me wrong - i understand the use case. but it is soemthing i do not want to support and spend time on. Feb 20 10:18:55 LetoThe2nd Why you do not care about VS ? Feb 20 10:19:05 gaston53: pay me, and then i will care. Feb 20 10:19:28 qschulz: Thanks, much appreciated :-) Feb 20 10:19:41 LetoThe2nd haha they are paying me, I am forced to care ;) Feb 20 10:20:28 gaston53: Have you seen https://www.yoctoproject.org/learn-items/using-vs-and-vs-code-for-embedded-c-c-development/ ? Feb 20 10:20:54 gaston53: then please care. seriously, whenever VS is involved, its a dead sure sign that some business forces are behind it. and i do not offer free services. thats why i specifically don't care about VS. other opinions are of course valid, i am speaking only for myself. Feb 20 10:21:18 gaston53: most likely some paths you haven't set so that VS can find your libboost in your SDK. VS should find the libboost from the SDK, not your build machine? But honestly, I'm a cli guy, so that's way out of my knowledge base now. GL Feb 20 10:21:33 erbo: nice one. Feb 20 10:21:52 I haven't seen it myself, but it seems quite relevant here :) Feb 20 10:22:01 erbo: i'll skim it for referral Feb 20 10:22:37 and the above statement really was not a personal rant or such. please do not take it as such, anybody. its just my POV. Feb 20 10:24:58 qschulz LetoThe2nd It's okey! by the way, I have succeded also to cross compile a program with VS whichi is on my windows machine and run it on Linux using Boost. I am going step by step .. you see .. Feb 20 10:25:32 the path of boost lib is not a problem Feb 20 10:26:11 Now I am facing a problem with SDK Feb 20 10:26:47 He can not set the compiler that I need into its configurations Feb 20 10:27:06 it's usualy using the default compilers generated bu VS Feb 20 10:27:08 by* Feb 20 10:27:38 LetoThe2nd Another thing, it's an early morning here in my country :D Feb 20 10:28:55 gaston53: its always early morning somewhere. Feb 20 10:36:51 LetoThe2nd qschulz I just want to ask, what I am trying to do is difficult or just me I am finding it difficult ? Feb 20 10:39:23 gaston53: it is not exaclty difficult in the technical sense, probably. but its something that is usually solved by hours and hours wasted in tinkering settings back and forth. only for the sake of some company insisting on using windows. Feb 20 10:41:33 LetoThe2nd I totaly agree with you ! ( but its something that is usually solved by hours and hours wasted in tinkering settings back and forth ) Feb 20 10:42:46 gaston53: and as it is a) time-intensive b) almost certainly not giving back any profit to the project or community - on the other hand, rather eating up support resources we have - i am highly reluctant to partake in such. Feb 20 10:43:24 gaston53: i mean, i'm pretty certain that there are solutions for that from vendors who base their products off yocto/OE technology. Feb 20 10:44:41 LetoThe2nd I see you are right Feb 20 10:48:02 * LetoThe2nd is impressed. new session on youtube, 100 view in the first 12 hours. Feb 20 10:53:55 LetoThe2nd: soon a rockstar I see Feb 20 10:55:13 qschulz: \m/ Feb 20 10:56:50 now i'm hungry. Feb 20 11:08:27 i am getting build error when i tried to build custom bsp layer with new machine type Feb 20 11:08:39 my board is based on imx6ulevk Feb 20 11:08:59 | /nobackup/sikumar3/inode_sumo/buildnew/tmp/work/imx6uloib-poky-linux-gnueabi/linux-imx/4.14.98-r0/temp/run.do_compile.11826: line 181: arm-poky-linux-gnueabi-gcc: command not found Feb 20 11:10:39 the error goes away if i rename the meta-mynode-board/recipes-kernel/linux/linux-imx_%.bbappend to meta-mynode-board/recipes-kernel/linux/linux-fslc_%.bbappend Feb 20 11:11:16 but the kernel build ignores my custom patches Feb 20 11:12:05 siva: there error goes away because it is not being built then. Feb 20 11:13:36 the error appears when it tried to build the kernel files. as soon as i change the name, kernel is build successfully. but my custom changes are not applied (dts, drivers.patch etc) Feb 20 11:14:24 siva: thats just what i said. if you rename th bbappend, it refers to a whole different recipe, which is not being built. hence the errors go away - as what you did is being ignored. Feb 20 11:15:17 siva: i would say, remove stuff from your bbappend until things start working again. Feb 20 11:16:24 ok, do i need to remove my custom changes (defconfig, drivers.patch, dts etc) until it builds? Feb 20 11:27:40 wow! it builds now without my changes Feb 20 11:28:17 it got stuck with | make[3]: *** No rule to make target `arch/arm/boot/dts/imx6ul-mynode.dtb'. Stop Feb 20 12:43:45 RP: whats the gst reproducible failure? Feb 20 12:48:30 rburton: that is fixed now, patch in master? Feb 20 12:48:42 ah cool just read the summary :) Feb 20 12:48:51 rburton: not upstreamed yet Feb 20 12:49:14 rburton: found another perl issue, makefile race. Upstream merged that fix an hour ago :) Feb 20 12:52:01 I'm having a hard time understanding the use for multiple strings in BBFILE_COLLECTIONS in conf/layer.conf. What am I missing? Feb 20 12:54:10 qschulz: i'm just having a hrd time. Feb 20 12:54:31 qschulz: its very old code, it predates layers Feb 20 12:56:36 RP: enjoying how perl-cross maintainer is responsive Feb 20 12:56:39 LetoThe2nd: I'm sorry, I didn't think calling off would make you that sad. Feb 20 12:56:52 RP: i don't think you broke master in my absence ;) Feb 20 12:56:55 qschulz: hrhrhr Feb 20 12:57:02 rburton: yes, we need to get some other things submitted Feb 20 12:57:06 RP: ack, thanks Feb 20 12:57:14 qschulz: nah, i'm just dabbling in some horrible js with an angular 1 frontend. Feb 20 12:57:24 rburton: heh, have to try harder :) Feb 20 12:57:35 qschulz: and my "contributions" are basically just making it even uglier. Feb 20 13:00:48 qschulz: OTOH, if we handn't called off we could get divorced. we're missing out on that. Feb 20 13:01:46 LetoThe2nd: I've been dealing with vendor out-of-tree WiFi driver for the last month. Damn race between main thread and interrupt handler. Fixed it, tested it... OH an other one later. I feel you. Feb 20 13:01:57 LetoThe2nd: we're missing on two parties. Wedding and divorce. Such a shame Feb 20 13:02:29 qschulz: and worst of all, a proper irish funeral! Feb 20 13:02:32 oh wait. Feb 20 13:02:40 that not realted, right? Feb 20 13:03:20 Any reason for https://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/externalsrc.bbclass#n172 other than use with devtool? Feb 20 13:03:37 I'm hunting down warnings and this "NOTE" message which isn't one is triggering me :) Feb 20 13:03:51 qschulz: you can use it standalone and it predates devtool! Feb 20 13:05:12 qschulz: specifically, that note is there to remind people its in use as for some scenarios, people forget Feb 20 13:05:18 RP: what do you mean by "it"? externalsrc? Feb 20 13:05:41 qschulz: yes. I didn't notice the n172 at first Feb 20 13:06:50 RP: I'm puzzled... If I decided I want externalsrc in my recipe, I have it? Why would I want a note? Feb 20 13:07:26 but since externalsrc is used with devtool, I definitely want to know when the devtool bbappend is applied which inherits externalsrc. SO that one use for the note which isn't one, I understand :) Feb 20 13:07:41 qschulz: its probably more devtools focused Feb 20 13:08:06 Could this be moved to devtool then? Feb 20 13:08:41 When it creates the bbappend in devtool's workspace? (just asking, I'm not asking for someone to write the patch ;) ) Feb 20 13:09:54 LetoThe2nd: you made me check what Irish Funeral is and the Urban Dictionary is definitely giving me weird vibes. Are you threatening me? Feb 20 13:09:56 qschulz: I'd guess. I'm not an expert on that code :( Feb 20 13:10:22 RP: alright, thanks. At least not opposed to the idea of that patch :) Feb 20 13:11:29 qschulz: We just don't have someone responsively maintaining that area of the code Feb 20 13:11:30 qschulz: https://youtu.be/D7g3RuoreRc Feb 20 13:11:50 I'm worried about it :( Feb 20 13:12:04 Looks like I fixed the last two non-reproducible build errors in my last 5.4 run Feb 20 13:12:26 RP: It just works (TM) Feb 20 13:12:28 I’ll submit a series later today once I collect one more fix that khem pointed to yesterday. Feb 20 13:13:14 qschulz: until people patch it and change it Feb 20 13:13:16 RP: (don't look up who are the latest contributors to determine the maintainer though ;)) Feb 20 13:13:40 zeddii: cool, thanks Feb 20 13:13:58 zeddii: perf fails on master with new binutils, looks like command whitespace issues :( Feb 20 13:14:54 RP: though it does not work (or does not work in an optimal way) if externalsrc is part of a git worktree but I haven't decided how to fix that properly yet (and we don't need it at work so... low prio). Feb 20 13:15:24 qschulz: first step would be to write a testcase! Feb 20 13:24:30 RP: that’s the patch that I have from khem. It’ll be in my series today. Feb 20 13:27:24 zeddii: ah, cool Feb 20 13:27:50 zeddii: also a bit worried about the whitespace command issue jwessel mentioned btw. Did we ever dig into that? Feb 20 13:28:37 no. I’ll have to dig up the original post. Was that where the flags order was implicated (even if not true)? Feb 20 13:29:43 zeddii: it was where a bit of trailing whitespace on the LD command (or some other toolchain variable) was breaking things Feb 20 13:30:08 I’ll troll my saved email and have a look. Feb 20 13:30:43 zeddii: it looked bad/odd but I haven't had time to poke :( Feb 20 13:30:57 zeddii: yes, we can hack fix it but it suggested deeper issues Feb 20 13:31:50 * RP starts to ponder the ptest log with 2.1 million lines performance "problem" Feb 20 13:39:14 Hi all. I'm back asking inane questions... Feb 20 13:39:29 So. I need the licences within my image. I can get this by setting a few vars in local.conf Feb 20 13:39:51 However I have two images (one large, one an initrd) within my yocto project, both for the same board. Feb 20 13:40:15 I don't believe those vars are applicable in an an image recipe, however I don't want the licences within the initrd. Feb 20 13:40:34 Is there a way to do this that's cleaner than appending the vars to local.conf in between image builds? Feb 20 13:41:06 JoeR: sounds like a use case for multiconfig, with the licensing add ons only in the main images configuration Feb 20 13:41:41 OK. I've not heard of multiconfig. I'm still stuck in Korgoth world (parallel dev to move forward to Thud). Is it available there? Feb 20 13:41:50 JoeR: technically it needs some tweaking, as you would have to include licensing texts that are only referring to software in the initrd then in the main image. Feb 20 13:42:08 JoeR: in thud, yes. krogoth, no. Feb 20 13:42:14 The initrd is a perfect subset of the main image at least. I do nothing clever. Feb 20 13:42:27 OK. So I'm stuck with my approach until I get to thud. Feb 20 13:42:32 That's ok. As long as I know. Feb 20 13:43:14 You're always so helpful. I say thanks again Leto! Feb 20 13:43:21 \m/ Feb 20 13:43:27 throw free beer! Feb 20 13:43:42 It's a long way from the UK to throw a beer! Feb 20 13:44:32 you'll never succeed if you don't try!!! Feb 20 13:45:03 Meh, I'm on the continent in a few weeks anyway. It'll be easier from there. Feb 20 13:45:19 * LetoThe2nd senses a lame excuse here. Feb 20 13:55:23 JoeR: which variables are these? Feb 20 13:59:00 COPY_LIC_MANIFEST, COPY_LIC_DIRS, LICENSE_CREATE_PACKAGE Feb 20 14:03:51 JoeR: COPY_LIC_* are image specific so you could override on a per recipe basis Feb 20 14:04:09 JoeR: The latter package creation is global Feb 20 14:04:41 OK. I might be able to do things in a better way then. Not sure I need package creation. Feb 20 14:04:46 JoeR: You could try LICENSE_CREATE_PACKAGE globally and something like COPY_LIC_MANIFEST_pn- ? Feb 20 14:04:57 OK. Feb 20 14:05:37 Is there any clever/quick way I can determine what you just told me? i.e. how can I find out where certain variables are applicable? Other than RTFMM? Feb 20 14:06:32 JoeR: well, I did a grep for COPY_LIC and then looked at where its used Feb 20 14:07:13 JoeR: the code looks image specific to me Feb 20 14:07:19 Righto. Just wanted to be sure I wasn't missing a trick. You've let me know of things in the past that magically make my life way easier. Feb 20 14:07:48 JoeR: it would be good to document variable context but we don't have that :( Feb 20 14:08:10 RP: i second that. That would be extremely nice :) Feb 20 14:08:22 qschulz: question is someone to do it Feb 20 14:08:42 It's a big project and it helps a lot of people. I'm just grateful it exists. I used ot have build distros entirely from scratch, this is a whole world better. Feb 20 14:09:27 JoeR: we are in some ways struggling to exist as nobody wants to help support the core :( Feb 20 14:09:58 JoeR: perhaps you could send a patch adding something to the manual about that class and those variables being image specific? Feb 20 14:10:19 RP: "the age of the everage RP increate by 1 each year" Feb 20 14:11:04 I'll see what I can do. Where's the manual live? Feb 20 14:11:16 JoeR: yocto-docs repo Feb 20 14:11:44 OK. I'm under pressure at work, but I'll see what I can do. Feb 20 14:13:24 JoeR: https://youtu.be/a01QQZyl-_I Feb 20 14:13:34 JoeR: well, hopefully we did just save you some time Feb 20 14:14:05 Indeed. I see that. People not so au fait with the open source world don't see things quite the same way. Feb 20 14:17:57 JoeR: I'm struggling to reply to that. Feb 20 14:18:52 JoeR: I do understand it, however the project could cease to exist if we don't find new contributors, even just for "small" things like docs tweaks Feb 20 14:19:15 and free beer! Feb 20 14:19:17 I say "small" since the whole project is build by many small incremental improvements building something greater. Feb 20 14:19:45 * LetoThe2nd gladly not only accept small free beers, also large ones! Feb 20 14:19:56 *will Feb 20 14:20:18 LetoThe2nd: I foresee a joint Yocto & craft beer convention in the future Feb 20 14:20:41 tgamblin: i'm not exactly fond of craft beer in many cases, but count me in. Feb 20 14:21:14 Is craft beer even allowed under the reinheitsgebot? Feb 20 14:22:49 JoeR: it is, yet maybe not in the same form of "craft" as in other countries. Feb 20 14:24:18 LetoThe2nd: Interesting. I've got quite used to weird lagers lately. Everything seems to be sour or with cucumber of some weird stuff. Feb 20 14:25:27 LetoThe2nd: JoeR: http://www.greatlakesbeer.com/Beer/octopus-wants-to-fight-ipa/ <-- exceptional Feb 20 14:26:19 tgamblin: hrhrhr. Feb 20 14:26:46 tgamblin: i'm just like more of augustiner edelstoff guy. Feb 20 14:26:47 anyone still using svn fetcher activelly? Did the path where the sources are checked out changed "recently" (before thud release)? Feb 20 14:27:22 I've taken some significant risks to keep the project alive, I'm starting to feel rather lonely on the "core" issues though and wondering why I keep doing it when its clearly making me ill. Looking at my buglist is totally depressing :( Feb 20 14:27:42 JaMa: there was a fix I just merged which may be relevant Feb 20 14:27:54 JaMa: not the last svn change but the one before Feb 20 14:29:00 RP: thanks, I'll check, I'm doing some world builds again and surprisingly all svn users in meta-oe are failing either to populate_lic or patch because of missing files (because S points to wrong dir) Feb 20 14:29:17 and I can reproduce it in thud as well as master (as of yesterday) Feb 20 14:29:27 and it's not listed in khem's report for some reason Feb 20 14:30:04 JaMa: hmm, we dropped all the svn urls from the core so its not that well tested now Feb 20 14:31:17 I already have "75223644 fetch2: svn: care for path_spec" if that's the one you had in mind Feb 20 14:31:33 RP: I was under the impression that the Yocto project had active support, active members funded by the larger corps? Intel etc.? Feb 20 14:32:00 [Sno]: around? Feb 20 14:33:00 JoeR: Intel has pulled back a lot of the people and is no longer doing development on the core. Other members have stepped up with funding and I'm now funded by that for example but what we're missing is people to do things :( Feb 20 14:33:41 RP: This is somewhat of a tragedy then :-( Feb 20 14:36:08 JoeR: I've put together contingency plan upon contingency plan but without developer time on issues there are limits on what can be done Feb 20 14:37:09 RP: That I can well believe. This is a small part of what I do as my job, that's only the case because Yocto exists though. Feb 20 14:40:49 JoeR: the model was we're all supposed to share the maintenance of the core. That isn't really happening as well as it needs to Feb 20 14:43:29 RP: Do many people understand the core? I just use Yocto as a tool, so have no real understanding of how it's working most of the time. Feb 20 14:46:31 JoeR: There are people but many are pulled onto other things by their employers Feb 20 14:46:57 JoeR: I've help train many over the years! :) Feb 20 14:47:15 RP: Everyones crushed. Late stage capitalism at its best. Feb 20 14:51:49 RP: can you write this as official YP statement somewhere so I can point relevant people to it and they might take it more seriously than just me warning them that there is this manpower issue? Feb 20 14:53:15 Hey peeps Feb 20 14:53:32 Is it possible to expand a bitbake variable with a cli helper app? Feb 20 14:53:44 RP: sometimes I also get an answer like "we're already funding the project" Feb 20 14:54:27 Something like (invented cli): "bitbake-expand DISTRO_VERSION" Feb 20 14:54:31 tempoDrom: what is your issue exactly? (bitbake myrecipe -e | less could help you) Feb 20 14:54:56 JaMa: Its been mentioned at the governing meetings but yes, I think we can do something Feb 20 14:55:20 The CLI can access variables.. (or so I thought).. but it takes some effort to access the data store for the backend. Feb 20 14:55:28 (I am assuming this is a bitbake cli) Feb 20 14:55:32 qschulz: Am trying to print some user friendly messages for the build users Feb 20 14:55:58 tempoDrom: just make a "something" that internally calls bitbake -e and parses it. Feb 20 14:56:37 LetoThe2nd: Guess that would work. Thanks :+1: Feb 20 14:56:56 Ooooh, fearsome bash script time ;-) Feb 20 14:57:31 tempoDrom: if it's in a recipe, ina specific task, use bb.warn() or something to print a message $VAR or d.getVar(VAR, true) if python. All depends what exactly you want to do and when Feb 20 14:57:36 JS! JS! you can do it in JS! Feb 20 14:58:45 I have to make a "sales pitch" to a dev which thinks yocto is complicated. And just wants to have something like: ./build dev or ./build release Feb 20 14:58:59 From whatever is the current git repo Feb 20 14:59:05 tempoDrom: you could also look at the tinfoil API Feb 20 14:59:07 I have it hooked under jenkins, one click for most people. Feb 20 14:59:09 * zeddii wants to reply to RP Feb 20 14:59:19 crap, enter key ruined that joke Feb 20 14:59:39 ahh yes, tinfoil, forgot the name of the API.. Feb 20 14:59:40 RP I was going to say, 18h to 12 seconds, is that the best you can do ? Feb 20 14:59:53 :P Feb 20 14:59:56 zeddii: :) Feb 20 15:00:06 tempoDrom: well if you have two different images or distros for dev or release, it's still only one line :) Feb 20 15:00:19 zeddii: was amazingly hard to see why that script didn't work Feb 20 15:00:41 So would like to show THat's all good, but want to give some echoing of the basics that will be built Feb 20 15:00:50 Like the DISTRO_VERSION and the IMAGE_NAME Feb 20 15:01:24 DISTRO_VERSION is already printed Feb 20 15:02:00 bitbake -e reparses all recipes, so it can take quite some time if you're doing it a lot Feb 20 15:02:17 tempoDrom: i'd go for kas + some nice config pretty-rpinting. Feb 20 15:02:36 That's true, but it's "hidden" within the other yocto related context which isn't important to whoever isn't doing yocto Feb 20 15:02:47 then you get a container-contained build in one line with pretty whatevers. done. Feb 20 15:03:01 LetoThe2nd: Don't know what kas is, checking.... Feb 20 15:03:06 tempoDrom: ugh... That's how we got dozens of warning messages. Because nobody reads them "it's just yocto" Feb 20 15:03:07 i take 10%, just so you know. plus a crate of beer. Feb 20 15:04:01 <[Sno]> JaMa: yes, around Feb 20 15:04:04 qschulz: I'll check it for daily builds, but this is for them to build locally and confirm the changes they made didn't break the system Feb 20 15:04:07 tempoDrom: teach them how to use Yocto. If they don't need it, I'd try to use a Yocto SDK so they don't have to care. Never used it though Feb 20 15:04:10 LetoThe2nd: Where do we ship this beer? Next Yocto-meet, for all the team? Or direct to you? Feb 20 15:04:38 JoeR: next yocto-meet of any form is fine. i'm happy to share. Feb 20 15:06:09 <[Sno]> RP: wrt. the make upgrade to 4.3 - I tried 2 setups with meta-mingw doing "bitbake core-image-mingw-sdktest && bitbake core-image-mingw-sdktest -c populate_sdk" - one musl+freescale/ls2088ardb and one glibc+intel/genericx86_64 Feb 20 15:06:17 <[Sno]> RP: neither one breaks on make Feb 20 15:07:21 [Sno]: you seem to be using svn fetcher as you were touching it last, can you please check http://lists.openembedded.org/pipermail/openembedded-devel/2020-February/205012.html ? Feb 20 15:07:46 [Sno]: it's not caused by your change for sure, I'm just interestd if you're seeing the same Feb 20 15:07:57 [Sno]: did you try "bitbake nativesdk-make" ? Feb 20 15:08:13 <[Sno]> RP: did - builds fine :( Feb 20 15:08:52 [Sno]: ERROR: nativesdk-make-4.3-r0 do_configure: QA Issue: This autoconf log indicates errors, it looked at host include and/or library paths while determining system capabilities. was the error Feb 20 15:09:10 [Sno]: I guess we'll have to rerun and get the config.log, see what its complaining about Feb 20 15:09:13 <[Sno]> RP: can I have the log ? Feb 20 15:09:24 [Sno]: lost now, we'll have to rerun Feb 20 15:09:38 <[Sno]> I'm pretty sure I have something on my build server which interferes Feb 20 15:10:18 [Sno]: https://autobuilder.yoctoproject.org/typhoon/#/builders/89/builds/1599 running Feb 20 15:10:27 <[Sno]> RP: thanks Feb 20 15:11:48 <[Sno]> JaMa: looks similar to my checkouts before my change ;) - except I used sth. like svn://svn.openmoko.org/sware;module=/src/target/gpio/trunk;path_spec=gpio Feb 20 15:12:11 <[Sno]> s,module=/,module=, Feb 20 15:13:39 [Sno]: can you try to build those 4 meta-oe recipes in your setup just to confirm it fail the same for you? Feb 20 15:15:33 <[Sno]> JaMa: sure - and I can dig deeper then - do I have to configure a special machine, or would qemuarm do? Feb 20 15:15:52 qemuarm should be fine Feb 20 15:16:14 it's just to find out what might be the difference between our builders, because khem's world build seem to be fine Feb 20 15:16:36 and I doubt this was broken since thud (and there aren't many changes in svn fetcher since thud) Feb 20 15:16:37 <[Sno]> probable EU/US issue? :) Feb 20 15:16:59 you mean Trump is behind it? Feb 20 15:17:01 <[Sno]> I will look soon - before weekend Feb 20 15:17:04 thanks Feb 20 15:24:45 [Sno]: https://autobuilder.yocto.io/pub/repro-fail/mingw/config.log grep for unsafe Feb 20 15:25:17 [Sno]: I know the build is still running but we have the log :) Feb 20 15:26:45 <[Sno]> it seems to add /usr/local/lib to -L - weird, smells - digging fot it Feb 20 16:02:54 qschulz: re the discussion about externalsrc a while ago, I regularly use it via local.conf or site.conf and find the note about what is being built externally helpful even w/o using devtool (which I also do sometimes) Feb 20 16:05:29 smurray: qschulz: Me too FWIW Feb 20 16:07:35 smurray: via local.conf? Feb 20 16:09:05 qschulz: yeah, INHERIT += "externalsrc", EXTERNALSRC_pn-foo = "/path/foo" Feb 20 16:17:20 isnt' that extremely inefficient? Feb 20 16:17:29 compared to devtool for example? Feb 20 16:17:53 because you're actually making all recipes inherit externalsrc and thus modify all recipes? Feb 20 16:18:08 what does it help you with that devtool cannot? Being curious here :) Feb 20 16:18:33 smurray: ^ Feb 20 16:21:09 qschulz: 2 reasons: 1) in my experience devtool falls down sometimes when patches are spread across .inc and .bbappends 2) there are times (basically all the time with AGL) when I cannot share a build directory across different platform configurations, and futzing with devtool options to try to share a common workspace is too much hassle Feb 20 16:22:31 qschulz: I basically only ever use devtool if I know the recipe I'm running it against is simple and the change is a one-off. I could be missing out, but I know externalsrc works Feb 20 16:23:24 1) only had issues with glibc (ah, that reminds me we still haven't worked that out with bluelightning :) ) and abuse in patchdir (patching files in the FS (well in WORKDIR) and not in the sources) Feb 20 16:23:50 I do not understand 2) (might be too late for my brain :) ) Feb 20 16:24:07 qschulz: and I guess a 3rd one, it's been my experience that devtool is a non-starter with kernel trees, that's a common usecase for externalsrc Feb 20 16:26:01 smurray: yup, debugged a few times the kernel with devtool, used manual compilation and tftp on my u-boot instead now, but that's a different process for sure. Could you explain 2)? Feb 20 16:26:08 but I understand that this message should stay here :) Feb 20 16:27:01 if you have time, it's just curiosity :) Feb 20 16:27:11 RP, kanavin_home: I pushed a fix for wayland with meson to meta-mingw/master-next Feb 20 16:27:40 qschulz: so AGL uses a script to generate the conf files, as it's known the BSP layers for different platforms won't interoperate. That means the easiest way to test multiple platforms is to have different build directories, so I can't easily test a change made with "devtool modify" on more than one platform w/o mucking around more Feb 20 16:28:15 qschulz: I'm surprised devtool works on the kernel for you, last time I tried it failed spectacularly Feb 20 16:28:30 smurray: gotcha. Feb 20 16:29:16 smurray: well... it was maybe on krogoth. But definitely not something newer than thud. And we've our custom kernel recipe (no kernel-yocto inherited for example), so maybe that changes a few things Feb 20 16:29:43 I just remember the time required for devtool to unpack and decided after two devtool that I wouldn't do that again :) Feb 20 16:31:47 JPEW: cool, thanks! Feb 20 16:51:24 JPEW: and then I promptly forget to set it :) Feb 20 16:58:32 JPEW: still fails: https://autobuilder.yoctoproject.org/typhoon/#/builders/89/builds/1601 :( Feb 20 16:59:56 One thing I noticed happening is that if I bitbake -c menuconfig virtual/kernel, any subsequent 'bitbake ' continues to build the default kernel. What's the step I'm missing to ensure my own config is built within the image? Feb 20 17:00:26 I resolve it by manually copying the .../.meta/.../.config file into defconfig, but surely that's not the right way to do things. :) Feb 20 17:00:49 ningauble: we've not come up with a good way to automate that step generically Feb 20 17:02:04 ningauble: -c savedefconfig, then take the defconfig at the exact same place. That's one more step. Cleaner file but not cleaner process Feb 20 17:03:07 Ah, right on, thank you. So a followup question, and shame on me for not just trying this myself, but does devtool deploytarget virtual/kernel root@ work in theory? If yes, any additional step for module deployment? Feb 20 17:03:36 err deploy-target, of course Feb 20 17:06:41 ningauble: try and let us know :p I'd say if it works, it works only in one very specific case where the kernel is loaded in U-Boot from the rootfs. But I don't know anything about that, just making assumptions (I don't see devtool knowing where to flash the kernel) Feb 20 17:07:16 RP: Hmm, I fixed that bug... Feb 20 17:07:49 Ah, right I fixed it in autotools... not meson :( Feb 20 17:15:20 sadly, YP didn't make the cut for GSoC this time :c Feb 20 17:16:11 I'm working with NXP iMX8QXPMEK evaluation board. I downloaded bsp release L4.19.35_1.1.0_MX8QXP from following site: Feb 20 17:16:11 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 20 17:16:12 This bsp release is for Yocto Project 2.7 (Warrior) Feb 20 17:16:12 I built yocto project for this bsp release. I copied built image into sd card and then booted NXP board from sd card. I need to step through USB Host Subsystem source code running in embedded linux kernel? Feb 20 17:16:13 There is a serial connection between my NXP evaluation board and my PC. Micro-USB Debug port in NXP board is connected to USB port in my PC. How do I setup debugging environment so I can see source code and symbols Feb 20 17:16:13 running in my NXP board? Feb 20 17:16:47 jani191: define "USB Host Subsystem" Feb 20 17:17:59 jani191: That's probably easier for NXP to answer than for us here Feb 20 17:18:00 if you're planning in debugging the kernel, I suggest the awesome slides: https://elinux.org/images/1/14/Linuxkerneldebugging.pdf Feb 20 17:18:16 qschulz: The kernel code that is part of Linux image created by yocto project has several subsystems. One of them is USB subsystem. Feb 20 17:19:15 jani191: so the actual question is how do I debug a kernel. It being built with Yocto isn't going to matter I'm afraid. You can contact NXP as paulbarker suggested or join the appropriate IRC chan for NXP kernels Feb 20 17:20:17 qschulz: Please let me clarify. I need to setup my debug / development environment. Feb 20 17:21:53 I don't even know if there is any problem with kernel. Maybe I shouldn't say that I need to debug kernel. I just need to setup Feb 20 17:21:59 debug environment. Feb 20 17:22:18 jani191: add gdbserver to your target image Feb 20 17:23:26 tlwoerner: Is there a way to check if gdbserver is already in my target image? Feb 20 17:24:57 jani191: I recommend starting with the project documentation at https://yoctoproject.org/docs/ Feb 20 17:25:12 Debugging remotely using gdb is covered there: https://www.yoctoproject.org/docs/3.0/dev-manual/dev-manual.html#platdev-gdb-remotedebug Feb 20 17:25:24 jani191: if you enabled buildhistory you can look in ${buildfolder}/buildhistory/images/${machine}/${clibrary}/${image}/installed-packages.txt Feb 20 17:28:48 paulbarker: ooh, that's good. i went looking for that recently and didn't find it. and i see some of the wording could use some tweaking ;-) Feb 20 17:29:21 tlwoerner: Inside ${buildfolder} there isn't buildhistory folder. I see following folders inside ${buildfolder}, cache, conf, sstate-cache, and tmp Feb 20 17:29:28 i was going to blog about that too, but now i have more ideas. ideally i'd like to see devtool help out with this :-) Feb 20 17:29:37 jani191: just means you havent' enabled buildhistory Feb 20 17:29:57 tlwoerner: How do I enable buildhistory? Feb 20 17:30:02 https://www.yoctoproject.org/docs/3.0/dev-manual/dev-manual.html#enabling-and-disabling-build-history Feb 20 17:30:30 tlwoerner: OK. thank you! Feb 20 17:30:53 paulbarker: Thank you! Feb 20 17:31:42 qschulz: thank you for having me clarify the question. Feb 20 17:33:15 jani191: You do not need to enable buildhistory to get a list of packages that went into an image. You can find it as tmp/deploy/images//-.manifest Feb 20 17:38:39 jani191: For some more information per package about what went into the image you can also do: oe-pkgdata-util -p tmp/pkgdata/ package-info -f tmp/deploy/images//-.manifest Feb 20 17:39:04 Saur: I have -.manifest open. Do I search for gdbserver in this file? Feb 20 17:39:23 jani191: Yes Feb 20 17:45:52 Saur: I searched for gdbserver in -.manifest but didn't find it. When I typed oe-pkgdata-util command, I got command not found Feb 20 17:46:30 Can I run oe-pkgdata-util command from anywhere? Feb 20 17:47:04 jani191: No, from an initiated build environment, i.e., same as where you run bitbake. Feb 20 17:48:41 jani191: Or technically, you can run it from anywhere if you specify the -p option as I did, but if the environment isn't initialized, then you need to give the full path to the oe-pkgdata-util script. Feb 20 17:49:27 jani191: And the relative tmp/ paths also assumed that you were in the build directory. Feb 20 17:53:26 Saur: I sent command from ${buildfolder}. I get: oe-pkgdata-util: command not found Feb 20 17:53:34 jani191: Typically you add tools-debug to EXTRA_IMAGE_FEATURES in your local.conf if you want to have gdbserver installed in the image. Feb 20 17:55:17 Saur: In my local.conf, EXTRA_IMAGE_FEATURES ?= "debug-tweaks" Feb 20 17:55:47 jani191: Yes. Change it to: EXTRA_IMAGE_FEATURES ?= "debug-tweaks debug-tools" Feb 20 17:56:12 jani191: That should give you gdb, gdbserver, strace Feb 20 17:57:25 Saur: Thank you very much! I will rebuild yocto project. Feb 20 18:03:16 hi, how do I install /lib/modules/$(kernel)/build/ in a kernel image to use systemtap with it? I thought adding kernel-dev would do it. Feb 20 18:52:27 RP, kanavin_home: Already I sent a patch to meson.bbclass that fixes MinGW (tested it this time :) Feb 20 18:52:48 I'm not sure if it's the "right" fix, so let me know what you think Feb 20 19:31:11 ok folks. now for something completely different (and almost serious): for $reasons YÖP seems to have massive lack in dev hours to even fix simple stuff. Feb 20 19:31:44 so who's in, if i announce to donate 5€ for every new contriutor that fixes an item of the newcomer bug list? Feb 20 19:39:15 JPEW: matthewzmd got help with his perl problem. matthewzmd explain how to run one perl test in the bugzilla entry please. Feb 20 19:39:38 ok Feb 20 19:42:12 vmeson: matthewzmd: OK, good :) Feb 20 19:49:30 Has anyone used the the yocto conan layer? Feb 20 19:49:34 https://docs.conan.io/en/latest/integrations/cross_platform/yocto.html Feb 20 19:51:37 matman1122: not yet, but it sounds interesting. needs a closer look at their fetching stage, though! Feb 20 19:58:50 Oh gods another language-specific package manager Feb 20 19:59:36 Searching "license compliance" in their docs gives zero results Feb 20 19:59:58 paulbarker: very good point. Feb 20 20:00:21 This is my drum and I'll keep banging it Feb 20 20:01:48 I assume it's a JFrog project with the aim being to have you sign up for Artifactory? Feb 20 20:03:32 https://github.com/conan-io/meta-conan/blob/master/classes/conan.bbclass - do_install is the correct step to fetch from the network right? Feb 20 20:03:51 I'm in a facetious mood today Feb 20 20:04:02 paulbarker: that why i said one needs to look at the fetch stage. *plonk* it is, then. Feb 20 20:07:02 Isn't conan a tool to install precompiled binaries? Feb 20 20:08:03 * tgamblin wonders what is best in life Feb 20 20:08:24 tgamblin: beer + heavy metal. Feb 20 20:08:36 tgamblin: + emacs Feb 20 20:08:55 neverpanic: Looks like it. Still should be doing network access in do_fetch and providing some way to distribute source alongside binaries for copyleft stuff Feb 20 20:12:46 So if I change my optimization flags in my distro conf packages downloaded by conan will just ignore that? Not sure if that's a tool I want. Feb 20 20:20:11 neverpanic: You're probably not their intended audience. Neither am I Feb 20 20:23:49 heh, I see no metadata about who has built the binaries on https://conan.io/center and there's no mention of signing anywhere Feb 20 20:24:04 seems a bit of a nightmare Feb 20 21:32:39 I'm working with NXP iMX8QXPMEK evaluation board. I downloaded bsp release L4.19.35_1.1.0_MX8QXP from following site: Feb 20 21:32:40 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 20 21:32:40 This bsp release is for Yocto Project 2.7 (Warrior) Feb 20 21:32:41 While back, I built yocto project for this bsp release. Today I made one line change to local.conf file. To rebuild image, do I need to: DISTRO= MACHINE= source fsl-setup-release.sh -b Feb 20 21:34:19 or do I just: bitbake Feb 20 21:35:49 jani191: It depends; if you already have the build environment sourced in your shell, the latter. Otherwise the former Feb 20 21:36:19 I would guess at any rate. I'm not familiar with that specific BSP Feb 20 21:37:32 JPEW: I only added "debug-tools" to EXTRA_IMAGE_FEATURES in local.conf file. Do I need to source build environment again? Feb 20 21:39:28 jani191: You should only need to source the environment once in a given shell session Feb 20 21:39:44 So, if you already have done that in your current shell, no Feb 20 21:40:10 Changes in local.conf don't require you to re-setup the environment. bitbake will detect the change and reparse Feb 20 21:41:11 JPEW: ok thank you! Feb 20 21:42:22 np Feb 20 21:44:17 $ source setup-environment My is just build setup_environment is one level above build Feb 20 21:44:29 What should be exact command Feb 20 21:44:41 to setup environment script Feb 20 21:49:17 jani191: Probably `source setup-environment build`, but again I'm not familiar with that specific BSP Feb 20 21:49:28 Try it and see what happens :) Feb 20 21:53:27 JPEW: I did 'source setup-environment ./build'. It basically says I can run bitbake . It says "Your configuration files at ./build have not been touched." It looks like it didn't do anything because there was nothing to do. Feb 20 21:54:20 Sounds reasonable Feb 20 21:54:40 Thats what I would expect from a well behaved SDK :) Feb 20 21:57:55 jani191: Your local configuration for the build are the files in build/conf/. You worked hard to created those files! you don't want the SDK to overwrite them because you re-sourced the build environment ;) Feb 20 21:59:42 JPEW: I just want to be clear that I'm not building SDK. I'm re-building yocto project. Feb 20 22:00:08 jani191: Ya sorry, I meant BSP Feb 20 22:00:46 JPEW: Thanks again. Feb 20 22:00:56 jani191: Some vendors package up Yocto with some scripts and call it an "SDK" Feb 20 22:03:01 some call it a "BSP", just depends on the vendor Feb 20 22:10:13 ok Feb 20 22:12:21 I added 'debug-tools' to my local.conf file, and now I cannot re-build image using yocto project: ERROR: Nothing PROVIDES 'core-image-minimal' Feb 20 22:12:21 core-image-minimal was skipped: 'debug-tools' in IMAGE_FEATURES (added via EXTRA_IMAGE_FEATURES) is not a valid image feature. Valid features: allow-empty-password allow-root-login dbg-pkgs debug-tweaks dev-pkgs doc doc-pkgs eclipse-debug empty-root-password hwcodecs nfs-client nfs-server package-management post-install-logging ptest-pkgs Feb 20 22:12:22 qtcreator-debug read-only-rootfs splash src-pkgs ssh-server-dropbear ssh-server-openssh staticdev-pkgs tools-debug tools-profile tools-sdk tools-testapps x11 x11-base x11-sato Feb 20 22:15:06 jani191: I think the one you are looking for might be "tools-debug" ? Feb 20 22:19:27 JPEW: That was it! Thank for that. Now it's building. Feb 20 22:38:39 Hi, any idea how I need to refer to a header file located in /usr/include/uapi/linux/ of a linux-stable recipe so that it ends up in the SDK? Feb 20 22:46:50 hmm, my irc client is not happy today :( Feb 20 22:52:09 RP: Not having much luck with the communication channels today Feb 20 22:53:25 JPEW: no :( **** ENDING LOGGING AT Fri Feb 21 02:59:57 2020