**** BEGIN LOGGING AT Mon Jan 13 02:59:57 2020 Jan 13 06:45:18 RP: I have sent a v2 for qemumips/vga issue which runs core-image-sato testimage fine Jan 13 06:46:18 RP: however, with glibc-2.31 I see that core-image-sato passes but core-image-sato-sdk does not boot I wonder what it does that crashes init system Jan 13 06:46:56 RP: sato-sdk is working ok on qemumips/glibc-2.30 so I think it pehaps is related to glibc 2.31 Jan 13 06:47:22 I will dig more into it. but things are now much better Jan 13 07:47:06 good morning Jan 13 08:06:18 Hi, im trying to add a user in a .bb file by adding inherit extrausers and setting the EXTRA_USERS_PARMS value with adduser test. but there is no new erntry in /etc/passwd Jan 13 08:09:39 hmw1: https://git.yoctoproject.org/cgit.cgi/poky/tree/meta-skeleton/recipes-skeleton/useradd/useradd-example.bb Jan 13 08:49:04 hello Jan 13 08:50:50 can anyone give me some advice here with bitbake build? Jan 13 08:52:04 nopeman: just state the problem/question and people will usually answer if they have ideas Jan 13 08:53:07 okay, so while i'm trying to build using bitbake core-image-weston i got this problem: Jan 13 08:54:56 http://bit.ly/2TecYxs Jan 13 08:55:51 im using ubuntu 16.06.6 LTS and following this instruction: https://elinux.org/R-Car/Boards/Yocto-Gen3 Jan 13 08:57:53 nopeman: seems like it's one of the binary drivers that's not found, did you download those drivers manually from renesas? Jan 13 08:58:01 yes Jan 13 08:58:29 all up to point when you build using bitbake core-image-weston is done Jan 13 08:59:51 can you check if the file RTM0AC0000XCMCTL30SL41C.tar.bz2 that bitbake can't find is located somewhere? Maybe check using find. Jan 13 09:00:27 I guess the idea is that it should be put inplace by the meta-rcar-gen3/docs/sample/copyscript/copy_evaproprietary_softwares.sh script, but maybe something went wrong Jan 13 09:00:38 yeah it's called EVARTM0AC0000XCMCTL30SL41C.tar.bz2 but that should be fine with Jan 13 09:01:08 it should be seen because of DISTRO_FEATURES_append = " use_eva_pkg" in previous step isn't it? Jan 13 09:01:42 well the recipe seems to be looking for RTM0AC0000XCMCTL30SL41C.tar.bz2, so maybe that flag hasn't worked as it should? Jan 13 09:03:14 can you check with "bitbake core-image-weston -e | grep ^DISTRO_FEATURES" how the DISTRO_FEATURE variable ended up? Jan 13 09:05:51 http://bit.ly/35MmtXj Jan 13 09:06:50 nopeman: so where did you put the DISTRO_FEATURES_append line? Doesn't seem to be used Jan 13 09:07:50 it's in local.conf Jan 13 09:07:51 http://bit.ly/2Nl7Rrv Jan 13 09:08:00 on # Evaluation packages Jan 13 09:08:56 Well, it's commented out :) Jan 13 09:09:36 well, thats probably it Jan 13 09:10:27 if i got any other questions see ya in another 4-5 hrs :) Jan 13 09:15:01 well i was too optimistic about it Jan 13 09:15:06 another issue Jan 13 09:15:06 http://bit.ly/2uBkNTt Jan 13 09:16:00 "which triggered exception OSError: [Errno 12] Cannot allocate memory" Jan 13 09:16:14 seems like you might run low of RAM? Jan 13 09:16:58 welp, i'll allocate more then Jan 13 09:17:02 thanks again Jan 13 09:23:04 no problem Jan 13 10:21:28 Hey, can anyone help me get the bigger picture around the bb.note and similar calls? Thinks like: what's the purpose for the wrapper? Are the print() calls in the codebase on purpose or legay? Stuff like that... :) Jan 13 11:18:42 Hi o/ Jan 13 11:18:53 what provides full dmesg over the busybox variant? my grep fu is failing me Jan 13 11:22:08 MeanEngi: I doubt there are many print() calls outside the UI Jan 13 11:22:39 MeanEngi: bb.note/debug are the user facing way of logging, internally bitbake moved to use the logger.XXX calls Jan 13 11:42:35 LetoThe2nd: LMGTFY :p "dmesg source code" => first link: util-linux/dmesg.c at master · karelzak/util-linux · GitHub. => https://layers.openembedded.org/layerindex/recipe/5601/ Jan 13 11:42:59 (that's how I usually do it :) I didn't know about it as well, but it worked for the last few times I tried) Jan 13 11:43:53 http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-core/util-linux/util-linux.inc?h=master#n226 Jan 13 11:44:17 qschulz: ah. i did the layerseries and grep layers thing, both failed me. thanks, next time gonna try that approach Jan 13 11:45:31 layerseries thing? Jan 13 11:45:45 qschulz: gah. layerindex. Jan 13 11:46:16 * LetoThe2nd is being totally confused and grumpy, because SQL Jan 13 11:46:16 (I recently discovered bitbake-layers show-* command and it's awesome, so if you have any "new" (to me) thing you're using, pleased to hear about it :) ) Jan 13 11:47:44 qschulz: i guess that this will be the $NEWCOOLHOTSHITZ: https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/scripts/oe-pkgdata-browser Jan 13 11:50:40 LetoThe2nd: from quick glance: knowing which packages are created from a recipe? Jan 13 11:56:42 you would think looking up PACKAGES would be enough, but that's not always the case Jan 13 11:57:12 but it's usually enough Jan 13 11:57:21 packages, dependencies, contents... Jan 13 11:57:42 nice Jan 13 11:58:31 milloni: PACKAGES_DYNAMIC for example, I know :) Jan 13 11:58:43 rburton: oh wow, nice, we're always unpacking the ipk manually to debug things Jan 13 11:59:11 qschulz: yes i was reading pkgdata directly or unpacking the ipkgs until i wrote that Jan 13 12:01:46 rburton: release 3.1 targetted I guess? Jan 13 12:07:40 rburton: where can i sent my advertising invoice? ;) Jan 13 12:14:04 New news from stackoverflow: Nvidia Jetson Nano with docker Jan 13 12:25:51 hey I got another issue with bitbake :http://bit.ly/35LU7fS Jan 13 12:26:50 built on Ubuntu 16.06.6 LTS, using instruction from:https://elinux.org/R-Car/Boards/Yocto-Gen3 Jan 13 12:27:27 anyone have any idea? Jan 13 12:31:06 qschulz: yes Jan 13 12:31:33 rburton: now I'm tempted to wait 3.1 before pushing the company to update :p Jan 13 12:35:56 qschulz: if you update now, you can update soon again! double the pleasure, triple the fun. https://youtu.be/U56KbegdkGs?t=62 Jan 13 12:36:08 @nope line 136 is the actual problem. Try to find out why it's missing Jan 13 12:36:16 nopeman i mean Jan 13 12:37:31 LetoThe2nd: in the future, that's the plan. I'd want to work on zeus now, so that when we release, 3.1 is just released and we can start porting on that one. Goal would be to have the latest-1 version so that we benefit from all the bugfixes and tests :) But we're not on that yet :) Jan 13 12:43:20 @stuom1 thanks, i just did that Jan 13 12:47:30 khem: A start job is running for Run pend…insts (2d 15h 46min 1s / no limit) <-- ha ha ha Jan 13 12:47:45 something tells me that it will not finish Jan 13 12:48:12 @stuom1 well online fix didn't help Jan 13 13:01:29 rburton: I wonder if we should put a tips section in the weekly status, the new ui could be a good candidate to highlight. Not sure I could come up with something every week though Jan 13 13:02:52 RP: rburton get in front of a webcam and show it! Jan 13 13:03:25 LetoThe2nd: not my thing, I have enough else to do without worrying about webcams ;-) Jan 13 13:03:43 otherwise, want me to give it a spin on the next session? planning is jan 21st Jan 13 13:03:49 RP: "new ui" should be part of the release note for sure. Jan 13 13:04:06 RP: but other than that, a random "tip" in the weekly status is nice :) Jan 13 13:05:32 hum. would it make sense to give a condenset wekly status on twitter/linkedin? i mean, those are channels we already have. and more content is always more good. just like free beer. more free beer is always better. Jan 13 13:06:47 LetoThe2nd: depends, do you want people to not read the mails anymore? that's a risk :) Jan 13 13:06:51 can I use "devtool modify" to modify a recipe (.inc file) from another layer? Just recipe, not source Jan 13 13:07:05 qschulz: i think those who are there don't read the ML anyways. Jan 13 13:07:23 so it would have to be like the executive summary. two lines about whats going on. Jan 13 13:07:37 stuom1: an inc is not a recipe. Jan 13 13:09:52 LetoThe2nd: paint me offended Jan 13 13:10:04 qschulz: can't i paint you black? Jan 13 13:10:25 ok, can I use "devtool modify" to modify a .inc file required by a recipe from another layer? Jan 13 13:10:41 stuom1: i don't think devtool is inc aware in any form. Jan 13 13:11:48 it there a wiki how to do that then? Jan 13 13:12:41 stuom1: use devtool modify on a recipe instead Jan 13 13:13:54 LetoThe2nd: it could be useful, the status report is a bit dry, its a necessary evil :/ Jan 13 13:14:06 LetoThe2nd: I don't enjoy writing it every week Jan 13 13:14:16 New news from stackoverflow: Yocto build: Debian Package Management error Jan 13 13:15:59 @rburton I'm currently trying that, but it fetches the sources to workspace but the recipe/inc is not in the sources Jan 13 13:17:21 RP: if it help, i'll happily do an executive summary digest based on your output Jan 13 13:17:28 stuom1: modify is to modify the *sources* isnt it Jan 13 13:17:37 if you want to edit the recipe, edit the recipe Jan 13 13:18:41 RP: actually, i think i have an idea. Jan 13 13:19:04 but it is somebody else's layer fetched online and not in my git Jan 13 13:19:24 do i just have to make a new recipe in my layer to override it Jan 13 13:21:19 stuom1: you definitely fetched the recipe if you built it Jan 13 13:22:10 Is there any public CI server that can test yocto layer for free? Jan 13 13:22:15 rburton: I think he wants to modify a .inc from another layer which he isn't a maintainer of Jan 13 13:22:29 dev1990: if you find one, tell us so we can slam it! Jan 13 13:22:30 stuom1: if ^ is correct, then look at .bbappends Jan 13 13:22:44 LetoThe2nd: damn it, you had to write between my two sentences didn't you :D Jan 13 13:23:35 dev1990: if you're careful, github etc CI will work. you'll want to use poky and point at the poky sstate mirrors to save time (building gcc will timeout the CI) Jan 13 13:23:39 yes I want a bbappend and I thought devtool modify is the way, but it seems to work only for sources Jan 13 13:24:14 as per the devtool docs, modify Modify the source for an existing recipe Jan 13 13:24:46 stuom1: you can use devtool to create patches basically or do active development on something Jan 13 13:24:53 if you want to edit a bbappend just create one Jan 13 13:25:19 i think kergoth has a bbappend-creating extension for devtool, he should submit it Jan 13 13:25:21 otherwise, it's a bbappend you want. devtool won't help fro that, it's just a text file that you write from scratch (there's nothing devtool or any tool can deduct for you for that) Jan 13 13:25:30 qschulz: of course. just to annoy you. Jan 13 13:27:09 well technically, you could use devtool to create the patches for the sources of the software built by the recipe and ask it to add the patches to your recipe (maybe even in a recipe) but honestly, it's not a big help and might even be counter-productive Jan 13 13:28:58 rburton: I'm using gitlab to test small qt aplication build and it takes around 3~min (but yeah preparation of sandbox takes some time too), my computer 4x4.0GHz Haswell takes about 20~30sec Jan 13 13:29:36 image bakeing for about 4h so I wonder what github will dilivers Jan 13 13:29:40 40hours Jan 13 13:29:42 ? Jan 13 13:29:49 HOW LONG Jan 13 13:29:53 delivers* Jan 13 13:30:02 dev1990: it will deliver nothing, just report a timeout. Jan 13 13:30:07 i can build core-image-sato from *scratch* in 45 minutes Jan 13 13:30:15 rburton: with how sstate Jan 13 13:30:17 and this is a four year old machine Jan 13 13:30:20 s/how/hot/ Jan 13 13:30:58 (the fast machines in the office do it in <30mins) Jan 13 13:31:18 rburton: I mean with clean build enviroment (and build my personal distro with stuff about 4800~ packages) Jan 13 13:31:57 dev1990: if you want to do builds that large you want persistent sstate, which no provider will do for free Jan 13 13:32:26 if you were building a small add-on layer then poky + sstate mirrors will give you everything but the pieces in the layer Jan 13 13:35:52 kk, just asking I found just that some official layers have their CI and I was wondering about "Comunnity edition CI" with some limits Jan 13 13:37:33 anyway thanks for tip for shared poky sstate, this may come handy on daily basis Jan 13 13:43:02 Anyone else unable to access lists.yoctoproject.org? Jan 13 13:43:49 I'm trying to look at the mail archives on groups.io, it's redirecting to lists.yoctoproject.org which is giving me NXDOMAIN Jan 13 13:43:56 NXDOMAIN here as well Jan 13 13:44:31 cloudflare and google dns agree.. Jan 13 13:44:50 Somebody must be watching, because it now resolves. :-) Jan 13 13:47:49 fullstop: Working for me as well Jan 13 13:48:18 halstead: ^^^ FYI, may just be a one-off weirdness though Jan 13 14:03:19 qschulz, rburton: recipetool has a few bbappend-creating subcommands, directly or indirectly. newappend, appendfile, appendsrcfile in particular Jan 13 14:03:22 * kergoth yawns Jan 13 14:03:45 not sure why we still have both recipetool and devtool Jan 13 14:07:00 folks, I am looking for the sysroot dir within yocto to get access to the glibc etc Jan 13 14:07:06 how would I approach this best Jan 13 14:14:28 New news from stackoverflow: How to build a working TPM2 image for Raspberry Pi with Yocto? Jan 13 14:19:06 rburton: yeah, it's a bit fuzzy. it seems like devtool was focused on the active development and esdk workflows while recipetool was for interacting with recipes more directly, but the boundaries are definitely not always clear. i sometimes feel like we could use a master 'oe' command with everything else under it, including 'build', but *shrug* Jan 13 14:19:12 or bb, or whatever.. Jan 13 14:19:25 Ö Jan 13 14:19:30 i vote for "Ö" Jan 13 14:23:16 Crofton|road: "they need networkd access" typo or finally getting into systemd? :P Jan 13 14:33:02 kergoth: i can't see why recipetool shouldnt merge into devtool (and exist purely as a "i think you mean devtool foo") Jan 13 14:33:12 as long as we stop devtool starting bitbake before showing --help Jan 13 14:33:16 which drives me insane Jan 13 14:34:04 that brings me back to, long time ago i submitted a patch to add a clean command to devtool. any reason it got lost / not merged? Jan 13 14:34:07 i think it's doing that to allow pulling plugins from BBLAYERS, but we shouldn't need a bitbake server for that, all we need to do is parse bblayers.conf. that said, iirc Cooker does that, and it parses both bblayers *and* bitbake.conf in its *constructor* Jan 13 14:34:41 course you could always use bb.parse directly and bypass that Jan 13 14:34:50 LetoThe2nd: probably because me and rp tend to let bluelightning review devtool patches Jan 13 14:34:52 probably cleaner to do a tiny bit of refactoring in the cooker though Jan 13 14:34:54 LetoThe2nd: ping the patch Jan 13 14:35:33 (it irks me that cooker parses bitbake.conf int eh constructor anyway, it means bitbake-layers remove-layer can't remove the layer that broke parsing) Jan 13 14:35:38 rburton: can't even find it, was years ago Jan 13 14:35:43 was planning to fix that but never got around to getting it merged Jan 13 14:36:34 rburton: https://www.yoctoproject.org/pipermail/yocto/2017-October/038596.html Jan 13 14:37:11 whats wrong with bitbake -cclean? Jan 13 14:37:24 is there a way to auto-reload udev when a package is installed? I can do it in postinst but I was wondering if there was something similar to SYSTEMD_AUTO_ENABLE for udev. Jan 13 14:37:45 rburton: that you don't have easy access to it in the esdk situation Jan 13 14:37:52 LetoThe2nd: good reason Jan 13 14:37:57 LetoThe2nd: rebase and repost? Jan 13 14:37:58 rburton: only reason, actually. Jan 13 14:38:18 rburton: more like repatch and repost :( Jan 13 14:38:33 rburton: once i find a couple of minutes, will do. Jan 13 14:38:35 fullstop: a postinst. if several recipes need it, write a class Jan 13 14:38:42 thanks Jan 13 14:39:23 I've found the source of my booting problems, and it's because of postinst stuff that I've added in my recipes. systemd stuff is touchy on the first boot. Jan 13 14:40:15 write it to run at rootfs time instead Jan 13 14:41:14 folks, I did a "bitbake meta-ide-support" but now I can't really find the toolchain :/ Jan 13 14:41:19 any help to make this work? Jan 13 14:41:56 a toolchain would usually be meta-toolchain or even better 'bitbake myimage -c populate_sdk' Jan 13 14:42:01 ends up in tmp/deploy/sdk/ Jan 13 14:44:41 is patchdir *officially* supported for applying patches on top of files coming from FILEPATH? (e.g. meta-a/recipes-a/a/files/myfile and a patch meta-b/recipes-a/a/files/patch-for-myfile.patch) Jan 13 14:50:44 RP: https://twitter.com/YoctoThe Jan 13 14:51:08 rburton: ok, I was using meta-ide-support. is that wring? Jan 13 14:51:10 *wrong Jan 13 14:51:23 maybe that's a question for bluelightning since he's sent a few patches to meta/lib/oe/patch.py Jan 13 14:51:36 Yatekii: yes. where told you do use that recipe? Jan 13 14:51:48 the description is 'Meta package for ensuring the build directory contains all appropriate toolchain packages for using an IDE' Jan 13 14:51:55 rburton: what does populate_sdk do differently? I basically want a toolchain in my build dir which I then can use from my rust package to build the application on the host :) Jan 13 14:52:19 Yatekii: in your build dir you have a compiler already Jan 13 14:52:23 more specifically, what I'm describing is supported but breaks devtool because the relative path to the files is then incorrect. I could try to dig into that but if we already know it's not gonna make it upstream, i'd rather not waste time :) Jan 13 14:52:44 rburton: https://www.yoctoproject.org/docs/1.8.1/adt-manual/adt-manual.html#using-the-toolchain-from-within-the-build-tree https://pagefault.blog/2018/07/04/embedded-development-with-yocto-and-rust/ both mention the ide support recipe :) Jan 13 14:52:45 rburton: lets see if this works as executive summary distribution path. Jan 13 14:52:50 and from what I understood I needed that Jan 13 14:52:56 but I can try and do the populate sdk Jan 13 14:53:05 god thats horrible Jan 13 14:53:10 Yatekii: that link to 1.8 is massively outdated, ADT is dead. Jan 13 14:53:29 LetoThe2nd: wll it's hard to tell when you are not toooo familiar ;) Jan 13 14:53:37 for you folks it might be obvious :D Jan 13 14:53:41 Yatekii: thats why we're telling. Jan 13 14:53:45 yeah :) Jan 13 14:53:55 thanks a lot! Jan 13 14:54:02 so imma try and do populate sdk Jan 13 14:54:54 ndec: i hope you're ok with the ambassador vs. jester "pun" :) Jan 13 14:55:37 ok that seems tro do something! Jan 13 14:55:39 \o/ Jan 13 15:00:19 did my ping to openembedded-core ML make it to the ML? Jan 13 15:02:54 qschulz: you made it to the udhcpd thread. Jan 13 15:03:11 LetoThe2nd: nice thanks :) Jan 13 15:12:34 can I use @bb.utils.contains on overrides ? Jan 13 15:13:11 something like that ${@bb.utils.contains('OVERRIDES', 'arm', '1', '0', d)} ? Jan 13 15:14:49 not sure about colon character, OVERRIDES have string like "foo:bar:foo:bar" Jan 13 15:16:34 dev1990: what are you trying to achieve? Jan 13 15:26:39 qschulz: I'm porting project that want override ARM=0 or 1 in oe_runmake Jan 13 15:28:42 It's using handwritten makefiles and etc, there is my strugles to write a class that supports many of "subproject" of libretro Jan 13 15:28:43 CFLAGS += "ARM=0" CFLAGS_arm += "ARM=1" ? Jan 13 15:28:44 https://github.com/dev-0x7C6/meta-retro/blob/zeus/classes/libretro.bbclass Jan 13 15:30:19 qschulz: this won't work some makefiles can do different stuff with this ARM define and more importantly it's makefile parameter not a compiler flag Jan 13 15:30:24 even better. ARMFLAG = "0" and ARMFLAG_arm = "1" and then use ARMFLAG where you could? might need to set vardeps on the tasks using it, I don't know exactly how well the detection works Jan 13 15:30:45 qschulz: my current solution is Jan 13 15:30:47 IS_ARM_ARCH ??= "0" Jan 13 15:30:48 IS_ARM_ARCH_armarch = "1" Jan 13 15:31:03 you don't need the ??= Jan 13 15:31:23 and IS_ARM_ARCH_arm = "1" instead of what you wrote Jan 13 15:31:27 That should be it yes Jan 13 15:31:28 where armarch is my override that is set when arch is arm, armeb aarch64 aarch64-be Jan 13 15:31:57 I wouldn't do that Jan 13 15:32:07 why ? Jan 13 15:32:15 use IS_ARM_ARCH_arch and then IS_ARM_ARCH_aarch64 etc... Jan 13 15:32:24 oh Jan 13 15:32:32 because it means that you have to manually add this OVERRIDES to your machines Jan 13 15:32:34 but what if it's redundant Jan 13 15:32:36 cumbersome Jan 13 15:32:36 How many log handlers are there in the bitbake codebase? Jan 13 15:33:04 dev1990: it'll work for any machine. Less error prone :) Jan 13 15:33:27 by that I mean you don't need to not forget about adding this OVERRIDES to your machines Jan 13 15:33:27 qschulz: well https://github.com/dev-0x7C6/meta-retro/blob/zeus/classes/retroarch-overrides.bbclass I'm using this class and overrides are added for my packages only Jan 13 15:33:50 without distro.conf or machine configuration Jan 13 15:33:59 And I guess this is then INHERIT+="retoarch-overrides"? Jan 13 15:34:03 +in Jan 13 15:34:04 no Jan 13 15:34:12 just using this as inherit Jan 13 15:34:18 for my custom package set Jan 13 15:35:04 honestly. I don't know how risky that is Jan 13 15:35:10 modifying OVERRIDES directly in a recipe Jan 13 15:35:43 Why aren't you using that but instead of OVERRIDES you use IS_ARCH_ARM? Jan 13 15:36:08 as long as its done in the recipe, the only thing that will bread is this, so ... go ahead and find out. as long as you're not doing stuff like this in a DISTRO or MACHINE that you ship, whatever. Jan 13 15:37:12 LetoThe2nd: OVERRIDES is cleaned before each recipe? No way you can contaminate the following recipes? Jan 13 15:37:52 qschulz: everything is cleaned before each recipe. one more time, aloud: "recipe data is local, conf data is global" Jan 13 15:38:33 dev1990: also, usually, one patches the Makefile with a patch instead of putting as much as possible in the recipe (well let's say, a compromise). Maybe also worth sending a patch upstream if you can. Less maintenance burden on the recipe, project nice to cross-compilers, 100% benefit Jan 13 15:38:51 so if you want to give yourself a headache in your recipes, go ahead. just make sure you don't hurt anybody else by injecting questionable stuff via conf, where it will affect the whole build. Jan 13 15:39:02 * qschulz screams while crying: "RECIPE DATA IS LOCAL, CONF DATA IS GLOBAL" Jan 13 15:39:16 qschulz: upstream don't like me, really Jan 13 15:39:59 https://github.com/libretro/RetroArch/pull/9995 Jan 13 15:40:09 you can find more there Jan 13 15:40:56 LetoThe2nd: mmm I'm wondering if the location in the file for this OVERRIDES would matter? Is the recipe flattened first and then resolves OVERRIDES and then resolves _myoverrides? Jan 13 15:41:18 otherwise if the order between the last two "and" is non guaranteed, ouch Jan 13 15:41:40 qschulz: no idea, beyond my expertise. Jan 13 15:42:41 qschulz: If you're intrested I can tell how it's playing in long term, for this is working for me fine Jan 13 15:43:29 dev1990: the famous "Works for me"© :) Jan 13 15:43:56 ;p Jan 13 15:44:16 before I ask about CI for yocto layers Jan 13 15:45:20 well on topic, i got oher makefile parameter ARM_FLOAT_ABI_HARD=${@bb.utils.contains('TUNE_FEATURES', 'callconvention-hard', '1', '0', d)} Jan 13 15:45:54 I think I'm looking for more consistent look Jan 13 15:46:37 ARM_FLOAT_ABI_HARD=${@bb.utils.contains('TELL_YOCTO_IS_THIS_ARM_FAMILLY_CPU', 'YES', '1', '0', d)} Jan 13 15:46:44 ups Jan 13 15:46:46 ARM=${@bb.utils.contains('TELL_YOCTO_IS_THIS_ARM_FAMILLY_CPU', 'YES', '1', '0', d)} Jan 13 15:47:32 ok final version: Jan 13 15:47:37 ARM=${@bb.utils.contains('TELL_ME_YOCTO_IS_THIS_ARM_FAMILLY_CPU', 'YES', '1', '0', d)} Jan 13 15:48:02 dev1990: I put a reply in for you Jan 13 15:49:58 thank you :-) Jan 13 15:50:46 * RP feels old Jan 13 15:51:02 dev1990: on the hackish way to do it, maybe you can set CC to ${HOST_PREFIX}gcc (maybe ${CCACHE} in front if that works) and appending ${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS} to CFLAGS? Jan 13 15:51:27 dev1990: FWIW CC="${CCACHE}${HOST_PREFIX}gcc ${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS}" by default Jan 13 15:57:33 hmm where exactly is the correct sysroot? :/ IU got one for each packet apparently in the build dir :/ Jan 13 16:16:29 Yatekii: a sysroot is constructed per recipe. Its mostly hardlinked for efficiency Jan 13 16:38:48 RP: yes, but where do I find it in the build dir Jan 13 16:38:57 I need it to build my application Jan 13 16:44:17 Yatekii: what do you need from the sysroot? Jan 13 16:44:55 qschulz: the toolchain, glibc, etc Jan 13 16:46:14 Yatekii: STAGING_DIR_TARGET and STAGING_DIR_NATIVE? Jan 13 16:46:24 ? Jan 13 16:46:29 I want a folder Jan 13 16:46:35 not an env var Jan 13 16:46:37 Yatekii: they are the variable names which contain the paths Jan 13 16:47:54 RP: both are empty Jan 13 16:48:13 Yatekii: then something's very wrong :) Jan 13 16:48:33 are they empty in your makefile (or whatever is used for building) or in the recipe? Jan 13 16:52:38 Yatekii: I guess the question is how you're trying to use them. They're not environment variables, they're bitbake datastore variables. It could put them in the environment if you ask bitbake to Jan 13 16:54:02 Yatekii: usually, when things are not compiling the way we want it to in Yocto it's because the makefile has some hardcoded CC, CXX, CFLAGS, CXXFLAGS, LDFLAGS, etc. --sysroot is passed as part of $CC, so try to check that your makefile use the one from Yocto ;) Jan 13 16:54:50 qschulz: RP: I just tried echo $STAGING_DIR_TARGET Jan 13 16:54:55 guess I was wrong Jan 13 16:55:13 qschulz: I dont want to alter a recipe just yet Jan 13 16:55:22 I want to use the built toolchain to build my application Jan 13 16:55:23 nothing more Jan 13 16:55:30 I then manually transfer it to the image Jan 13 16:55:35 once it works I'll build a recipe Jan 13 16:56:03 Yatekii: Sounds like you want to make an SDK Jan 13 16:56:08 no Jan 13 16:56:23 JPEW: I have the yocto sdk target already built Jan 13 16:56:56 I just don't know which directory in the convoluted build dir (the prompt ius over 3 lines long lol ...) isthe actual sysroot of the sdk Jan 13 16:57:58 Yatekii: I didn't realise you were using the SDK. Not sure there is a specific variable there but the path should be in the CC command Jan 13 16:58:39 $CC should be enough I think for you Jan 13 16:59:54 hmm ok I'll have a look, sec Jan 13 17:09:51 RP: qschulz the $CC bitbake var? Jan 13 17:10:40 how would I proitn that? Jan 13 17:10:44 *print Jan 13 17:11:21 Yatekii: source the SDK environment file, echo $CC Jan 13 17:12:21 RP: could it be this: st-image-tkrt-openstlinux-tkrt-stm32mp1-raichu-cubemx-x86_64-toolchain-2.6-snapshot.sh ? Jan 13 17:15:06 I just find an installer :/ Jan 13 17:15:09 (the file I pasted) Jan 13 17:15:52 Yatekii: the above should have an archive appended to the script which it would extract when you run it Jan 13 17:16:21 Yatekii: its very unclear what you're trying to do things with though Jan 13 17:16:27 yes, I just installed the SDK Jan 13 17:16:35 but I don't really want that Jan 13 17:16:43 I want to use it diorectly from the build directory Jan 13 17:17:02 why create a binary installer archive which you then have to install everytime you modify your yocto distor? Jan 13 17:17:07 it's plain pain Jan 13 17:18:52 Yatekii: right, so you want to use bitbake itself and use its toolchain from the build env Jan 13 17:19:45 yeah, how would I go about this? I was advised to build the sdk Jan 13 17:22:43 Yatekii: I suspect bitbake meta-environment- and then sourcing the environment file would do it Jan 13 17:23:30 I still suspect writing a recipe would be easier as that way you can declare your dependencies Jan 13 17:26:20 RP: sourcing the environment file didn't help as I stated already Jan 13 17:26:57 I mean wtf the entire toolchain is there inside the build dir and just because I cannot use it, because someone felt fancy with views and stuff Jan 13 17:33:55 How many log handlers are there in the bitbake codebase? I'm noticing print() / bb.plain() / logger.info() Jan 13 17:34:17 Is it context specific where each is used? Jan 13 17:35:27 bb.plain is probably for everything happening on the cooker. And if I got correctly that gets shipped back to the UI module through pipes as "events" Jan 13 17:36:44 Yatekii: meta-environment creates an environment file which behaves similarly to the sdk Jan 13 17:37:14 MeanEngi: logger.* and bb.XXX all become LogMsg events Jan 13 17:41:46 RP: Thanks. Does that imply a separate thread or something responsible for handling those events? Or would that fall into the authority of the ui_module? Jan 13 17:43:16 RP: ohhh Jan 13 17:48:41 RP: ok the command executed successfully. where would I find that environment source file? Jan 13 17:53:44 MeanEngi: the UI module listens and turns them into print() and writes them to log files etc Jan 13 17:54:17 Yatekii: probably tmp/ iirc Jan 13 17:55:05 RP ur a god, thx so much foir the support :) qschulz too! Jan 13 17:55:09 btw I am trying to use rpmsg with this: https://wiki.st.com/stm32mpu/wiki/Linux_remoteproc_framework_overview specific example. unfortunately I can't see any ttys comming up when I start the remote process. is anyone familiar with the stuff? Jan 13 18:23:28 Hi to everyone! Jan 13 18:34:07 Hello! I would like to "depend" on a binary from another recipe. The binary is packaged to a ${PN}-bin, but afaik you can't depend on packages. I need the binary at configuration time. Jan 13 18:42:17 roussinm: Is it a native binary? Jan 13 18:52:50 How does one get a very minor change into the YP Reference Manual? The instructions for setting up Fedora hosts should include rpcgen in the package list, but it doesn't Jan 13 18:55:23 tgamblin: actually one needs rpcsvc-proto Jan 13 18:55:35 khem: even better! Jan 13 18:56:03 which should be common across all new distros Jan 13 18:56:58 so I guess, you can send a pull request to https://git.yoctoproject.org/cgit/cgit.cgi/yocto-docs/ Jan 13 18:57:39 instrs are here https://git.yoctoproject.org/cgit/cgit.cgi/yocto-docs/tree/README Jan 13 18:58:21 khem: thanks! Jan 13 19:44:19 roussinm: really depend, so you need the -bin thing at build time? then DEPENDS = "whatever-native". if you need the thing at runtime, then RDEPENDS_${PN} = "whatever-bin" Jan 13 19:45:32 LetoThe2nd: TheYoctoJester? Jan 13 19:45:38 jonmason: AYUP Jan 13 19:46:03 I literally laughed when I saw that and knew it had to be you Jan 13 20:06:39 jonmason: will kvm work if I have aarch64 host ? iow, `runqemu kvm` ? Jan 13 20:07:13 khem: sort answer is "it depends, but most likely yes" Jan 13 20:07:44 not all aarch64 is guaranteed to have aarch32 support Jan 13 20:07:48 I like 'it depends' since then you are always right Jan 13 20:07:52 but iirc, all should support kvm Jan 13 20:08:01 khem: runqemu kvm? is that new magic? Jan 13 20:08:43 LetoThe2nd: if you do runqemu --help then you will see it :) Jan 13 20:09:35 helps tremendously, when you use similar build and target eg. qemux86 or qemux86-64 Jan 13 20:09:44 khem: i see, thanks Jan 13 20:10:04 kvm is 4x speedup on my Softiron board Jan 13 20:10:11 and if you also use llvmpipe then I can see 40fps on cinematicexperience demo which is darn good Jan 13 20:10:16 maybe even more than that Jan 13 20:12:00 what do you guys use for communication between your embedded devices? Considering grpc for the next generation running on Yocto systems. Jan 13 20:12:02 LetoThe2nd: if you run -ctestimage a lot then just set QEMU_USE_KVM = "1" in local.conf helps Jan 13 20:12:31 Before I was using raw TCP :P I'm actually worried about using a large libraries like grpc from a debuggability POV. Jan 13 20:12:39 khem: i never test. once my stuff compiles, i ship it! Jan 13 20:12:43 LetoThe2nd, mah man Jan 13 20:12:55 that's what the customers are for Jan 13 20:13:01 LetoThe2nd: you are among 90% of people then :) Jan 13 20:13:17 rangergord: re communication, it depends. never used grpc so far, though Jan 13 20:13:28 khem: but hey, i'm being honest about it. Jan 13 20:14:31 LetoThe2nd:yeah Jan 13 20:15:10 but while we're at it. i tried to dig into runqemu a bit. and while nographic is obvious, there seems to be nothing like "nonet" or such Jan 13 20:15:23 LetoThe2nd, what *have* you been using then? I know the big solutions backend devs use (grpc, RabbitMQ, socket.io, pure HTTP, etc), but embedded is different Jan 13 20:15:27 JPEW: Yes native binary. LetoThe2nd I'll try that. Jan 13 20:15:47 which means it will always try to do the tun/tap, and therefore sudo dance, right? Jan 13 20:16:01 rangergord: so one project I have to strip off dbus and go to websockets, you have to see what resources and workloads you have to deal with Jan 13 20:16:21 rangergord: well i know of folks who use mqtt, for example. Jan 13 20:17:19 rangergord: and really, it depends totally on the workload, not on some fancy tech name. many of the things are conceptually very different. Jan 13 20:17:22 nanomsg is quite good and addressed shortcomings of mqtt but its PITA to contribute to it Jan 13 20:17:26 yeah, I read about MQTT but it requires a broker which I won't have. I want something that works peer-to-peer. Jan 13 20:17:56 rangergord: who says that you can#t run a broker on your device? Jan 13 20:17:59 khem, I was actually thinking of websockets + protobuf for messages Jan 13 20:18:05 rangergord: -> mosquitto Jan 13 20:18:21 rangergord:yes that combo works pretty well on low end devices, I can confirm Jan 13 20:18:26 LetoThe2nd, well...let's say I have 5 devices. I can't have comm between 4 of them break down because the 1 that acts as broker was being serviced Jan 13 20:18:47 rangergord: who says you can' have 5 devices who each is a broker? Jan 13 20:18:57 *can't, even Jan 13 20:19:12 yeah broker architecture does have scaling issues Jan 13 20:20:03 see that already sounds conceptually messy Jan 13 20:20:24 rangergord: don't get me wrong, i'm not advocating the MQTT case. what i'm saying is that, understand your prolem fully first, and then pick a solution. don't say "i don't have a broker, so thats out. i don't have js, so thats out... so the only one left in the end mus be my solution" Jan 13 20:23:03 having said that, i am very fond of json as transport protocol, but that may be just me. Jan 13 20:23:39 OK...my problem is that I want a crossplatform pub/sub peer-to-peer system that's simple to understand and debug, doesn't require tons of boiler plate code, isn't Billy's Personal Github Project, gives me control over the connections (heartbeat, reconnect, etc). Many fit these requirements, so I go a bit further: what's the most popular/established Jan 13 20:25:55 wow, thats quite a mouthful. no idea, i don't know anything that ticks all the boxes. Jan 13 20:37:06 other than MQTT, actually, now that i think about it. Jan 13 20:40:03 crossplatform: [X]. pub/sub: [X]. peer-to-peer: [X] (by running client and broker). understand- and debuggable: [X]. amount of boilerplate: [not worse than others]. connection control: [X]. established, not a one man show: [X] Jan 13 20:40:34 on the other hand, as you say "many fit these requirements" - which? so i can have a look and learn too? Jan 13 21:05:02 well, I found grpc, captain proto, socket.io, nanomsg. grpc is the biggest one, pushed by Google and Microsoft as the suggested way of using APIs. Jan 13 21:17:17 Thanks LetoThe2nd and JPEW I was able to send my patch. Is this documented somewhere that if you depends on -native recipe you get "all" packages (not sure about this)? Jan 13 21:39:21 LetoThe2nd: re: runqemu and "nonet", if there isn't a "nonet" there is the "slirp" option which doesn't require elevated privileges. But you will still have network availability in the guest, so if you really want "nonet" it may need to be added Jan 13 21:52:53 kergoth: I'm wondering if we shouldn't use tuples instead of the task ids in runqueue... Jan 13 21:53:35 hmm, not a bad idea, more self-describing, could use a namedtuple at that Jan 13 21:53:38 JPEW: ^^^ may be of interest to you too Jan 13 21:53:57 What would be in the tuple? Jan 13 21:54:04 kergoth: http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=master-next&id=d6f468f5b67407c730c67c94d3787696d38a634f :) Jan 13 21:54:15 kergoth: this is what got me thinking about it being wider than that Jan 13 21:54:18 aside: it's amazing how much less shitty dev is on windows with WSL, Windows Terminal, and VSCode Jan 13 21:54:49 JPEW: see that patch, basically avoid all this split(":") Jan 13 21:55:08 kergoth: I can imagine, I've been playing with vscode Jan 13 21:55:27 the Remote extensions are fantastic. using SSH and WSL every day with it Jan 13 21:55:57 kergoth: I'm not quite there yet as the key combinations keep breaking things for me but I should try again Jan 13 21:56:45 kergoth: I guess we need some patches to test and profile Jan 13 22:00:50 From yocto build, building u-boot, i am getting this: "Your GCC is older than 6.0 and is not supported" ... how to fix this ? need to roll back to an older u.boot ? Jan 13 22:03:43 kergoth: https://stackoverflow.com/questions/2646157/what-is-the-fastest-to-access-struct-like-object-in-python Jan 13 22:04:19 angelo__: build on a newer distro? We also have a WIP buildtools tarball with a newer gcc Jan 13 22:05:15 kergoth: I wonder if bitbake runs on pypy... Jan 13 22:05:55 I tried it once many years ago after fixing a few minor cpython-isms, iirc it didn't help a lot just due to our particular resource usage Jan 13 22:05:58 worth trying out again Jan 13 22:06:13 kergoth: yes, might be quite different now Jan 13 22:11:45 RP, thanks. Strange btw, i am using a version (2018.01) that's seems to be for sumo, i am in sumo, but getting compiler erreor Jan 13 22:20:34 angelo__: I'd check you're really building what you think you are as that sounds a little odd Jan 13 23:01:09 What's the new naming convention for yocto releases? Jan 13 23:02:40 cve_check is broken on sumo :c do you think that cherry-picking commits found in newer releases would work in bringing the new cve-check-db in? Jan 13 23:05:13 rburton: fyi, looks like bb-var needs tweaking to handle a multiconfig target. mc:foo:bar, gets NoProvider Jan 13 23:07:29 places in england? driving me nuts! Jan 13 23:10:13 nate02: as with the other schemes, you'll likely need a few entries to get it :) Jan 13 23:10:24 kriive: yes Jan 13 23:56:02 is there any additional benefit for using SECTION in recipes? Jan 13 23:59:14 dev1990: typically, o Jan 13 23:59:15 no Jan 13 23:59:29 useful if you're maintaining a feed and want an human-readable index Jan 14 00:13:03 what might be adding "/dev/sda1 /boot vfat defaults 0 0" to the /etc/fstab after rootfs was created? I'm seeing it e.g. in core-image-sato-sdk-qemux86-64.rootfs.ext4, but it's not in WORKDIR/rootfs/etc/fstab for me it breaks the boot with systemd as there is no /dev/sda1 and boot waits forever for that (noticed when trying to debug -c testimage getting stuck until it timeouts waiting Jan 14 00:13:09 for login Jan 14 00:49:51 JaMa: are you using wic ? Jan 14 00:50:28 khem: not really intentionally, but there was IMAGE_FSTYPES="wic.vmdk ext4 wic wic.bmap" Jan 14 00:51:44 wasn't the issue with wic modifying it for other image types already fixed? let me find the commit Jan 14 00:53:55 http://lists.openembedded.org/pipermail/openembedded-core/2019-October/288505.html Jan 14 00:54:40 ah it looks like it never made it pass Ross Jan 14 00:54:55 yep Jan 14 00:57:29 so it's either openembedded-core/scripts/lib/wic/canned-wks/common.wks.inc expecting /boot partition which doesn't exist, or the /dev/vda image used by runqemu should actually use different disk which had separate /boot partition Jan 14 00:58:06 it was happening only for -sdk images, so I was looking in wrong direction :/ Jan 14 01:44:03 is it normal that 'oe-pkgdata-util find-path' can't find directories? Jan 14 02:31:28 mischief: whats your full cmd ? Jan 14 02:31:34 and have you built an image ? Jan 14 02:35:00 RP: if all goes well, I'll have 5.4 ready by the end of this week + the new libc-headers. I fixed a few more issues today, but I have -rt, aufs, yaffs2, etc, all ported now and am running glibc tests. will do musl tomorrow and the AB after that. Jan 14 02:44:37 khem: oe-pkgdata-util find-path /var Jan 14 02:44:46 or /var/tmp, or /var/log, so on Jan 14 02:45:37 if i inspect the built base-files package, of course it has /var, so thats what i expected this to print. Jan 14 02:45:56 and yes, i have an image. Jan 14 02:55:42 mischief: it works on filenames **** ENDING LOGGING AT Tue Jan 14 03:00:09 2020