**** BEGIN LOGGING AT Wed Oct 28 02:59:57 2020 Oct 28 07:38:29 yo dudX Oct 28 08:09:27 I have a trouble about how to set /etc/resolv.conf. I built the core-image-sato image. And its content of /etc/resolv.conf is # Generated by Connection Manager Oct 28 08:09:27 file? Oct 28 08:13:11 Sorry, spell mistake.Retext it. I have a trouble about how to set /etc/resolv.conf. I built the core-image-sato image. And its content of /etc/resolv.conf is # Generated by Connection Manager Oct 28 08:13:11 like "nameserver 8.8.8.8" to this file? Oct 28 08:15:13 adally: that probably depends on the connection manager in question. please note that sato is not really an image to base your project on, more like a demonstration/testing vehicle Oct 28 08:33:21 LetoThe2nd Thanks. It seems /etc/resolv.conf is always softlink to a file named resolv.conf in /run or /run/x/. I used sato to try something which needs display and run the image with runqemu. Oct 28 08:34:40 adally: i've never used sato, so i cannot really comment properly. but if that links to /run, it seems that it has been created by connman or such. so the real question is probably, how to inject additional configuration there. Oct 28 08:37:51 good morning everyone! Oct 28 08:38:28 there's someone that can help me with an issue on Dunfell version ? Oct 28 08:39:02 Massimo: sure! you're in the right place Oct 28 08:40:37 letothe2nd: Yes. It's the real question. root@qemux86-64:/etc# cat resolv-conf.connman Oct 28 08:40:39 resolv-conf.systemd Oct 28 08:42:06 LetoThe2nd root@qemux86-64:/etc# cd /var/lib/connman/ Oct 28 08:42:08 192.168.7.2/255.255.255.0/192.168.7.1 Oct 28 08:42:36 adally: it seems to come from http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-connectivity/connman/connman-conf.bb?h=master Oct 28 08:43:02 adally: so you would create a bbappend to that and replace it with the stuff you want. Oct 28 08:45:21 mckoan: tnx! i've just asked on stackoverflow a week ago....i don't know if i can post the url so you can read all the steps. Anyway....i've made a custom image of Yocto Dunfell on my Rpi3. I need to install NodeJS version 6.10.3 so i've added meta-nodejs as repo ...but when i try to bitbake nodejs ...gives me an error about "env python: not found". As workaround, i've tried to download a Oct 28 08:45:22 precompiled version of nodejs for armv7l and create a custom recipe. It bitbakes without errors...but once burned the image on SD card... node gives me a "Segmentation fault" error. Oct 28 08:45:39 mckoan: this is the url on stackoverflow: https://stackoverflow.com/questions/64495178/yocto-dunfell-correct-way-to-install-pre-compiled-binaries Oct 28 08:46:39 the strange thing is that on my Host OS ....node binary file...differs from the package to the one on image dir Oct 28 08:47:09 LetoThe2nd Thx. It's the connman. Oct 28 08:47:34 Massimo: nodejs 6 is massively outdated. and as we have a proper nodejs recipe in meta-openembedded, i would strongly recommend to just use that. Oct 28 08:48:23 LetoThe2nd: i know!! but i need that specific version Oct 28 08:48:49 Massimo: trying to package it as a precompiled binary is absolutely discouraged... and meta-nodejs is basically deprecated since we have nodejs in meta-openembedded. Oct 28 08:49:39 Massimo: well then the sensible approach would be to create your own layer, rip off the recipe from meta-openembedded, and try to set the version backwards. might require some patching, though. Oct 28 08:49:56 Massimo: then set your distro to request your version by PREFERRED_VERSION Oct 28 08:50:07 its no magic, just tedious. Oct 28 08:50:32 (unless nodejs 6 does not build anymore with the gcc version in dunfell. then you're screwed.) Oct 28 08:51:29 heh, or if it requires python2. then you're also screwed. Oct 28 08:53:06 yep....and that's what i have done. Everything with the "bitbake" process runs fine. The issue is on the pre-compiled file. Once launched Yocto no my RPi...node --version return "Segmentation fault". So i've downloaded directly the binaries...and brutally copied with "cp" and it just runs fine! Oct 28 08:53:44 what you're saying contradicts what i just said. i nowhere mentioned using binaries. Oct 28 08:54:51 you might look into the binaries being stripped upon packaging. that can be avoided by INHIBIT_STRIP = "1" or some thing pretty close, please look it up yourself in the manual. Oct 28 08:55:47 LetoThe2nd: ok ....remove "nodejs"..... i made a recipe that copy a pre-compiled binary on my image rootfs.. the binary package that yocto creates during the process differs from the original one. Oct 28 08:56:05 * LetoThe2nd shrugs. i jsut said everything that is to be said about it. Oct 28 08:57:20 LetoThe2nd have you looked the url i've posted ? Oct 28 08:57:55 nope. i am totally not interested in stackoverflow. Oct 28 08:58:39 and as you obviously are completely ignoring all effort i have invested in explaining, and are trying to stick to your precompiled approach, i will end here now and focus on getting more coffee. Oct 28 08:58:42 good luck! Oct 28 08:58:58 O_o Oct 28 08:59:03 wow Oct 28 08:59:33 there's someone less toxic that can help me on this issue pls ? Oct 28 09:13:03 :) i had a yocto setup for 48 threads, while my machine has max 24. Effect of this was incredible, mouse paralized, browser windows crashing with errors, and so. Oct 28 09:14:04 Should yocto prevent using more threads than the max available ? Oct 28 09:17:13 angelo__: maybe checkout https://www.yoctoproject.org/docs/current/bitbake-user-manual/bitbake-user-manual.html#var-bb-BB_NICE_LEVEL Oct 28 09:18:26 Hi LetoThe2nd , thanks. Oct 28 09:18:39 i registered for tomorrow summit :) Oct 28 09:19:16 angelo__: awesome! note, you can already join the slack, we're already around. Oct 28 09:19:27 ooh good :) Oct 28 09:19:45 https://join.slack.com/t/theyoctoproject/shared_invite/zt-i5tjtidz-EgHG4cq4c7fLn_0PXT3~IQ Oct 28 09:22:23 angelo__: BB_NUMBER_THREADS and BB_NUMBER_PARSE_THREADS didn't help? Oct 28 09:22:45 mckoan, thanks, yes i reduced the threads, all works :) Oct 28 09:22:58 Good morning, fine ppl Oct 28 09:24:36 mckoan: angelo__ well theoretically with higher thread cout and finely tuned nice you could get a little bit faster completion.. :P but i'd say that its probably not worth the effort, and just limiting _THREADS does the trick well enough, yes. Oct 28 09:24:50 carlsb3rg: howdy. whenever i read you nick, i want a beer. Oct 28 09:25:51 Not necessarily a bad thing :D Oct 28 09:26:15 yup Oct 28 09:30:51 as a birthday present, I ordered myself a Pi that I will use exclusively to increase yocto competence... Oct 28 09:33:22 awesome! i am also considering to order myself a bottle of nice scotch as a birthday present that i will exclusively use to increase my yocto (in)competence! Oct 28 09:34:24 Drunken Master II? Oct 28 09:35:35 hehe Oct 28 09:44:02 i've just tried with INHIBIT_STRIP = "1", INHIBIT_PACKAGE_STRIP = "1", INHIBIT_SYSROOT_STRIP = "1" ....but same result :( Oct 28 09:44:04 root@sentinel:/opt/node-v6.10.3-linux-armv7l/bin# diff node /usr/bin/node Oct 28 09:44:04 Files node and /usr/bin/node differ Oct 28 09:44:14 why if it's only a "cp" ?! :°( Oct 28 09:54:37 Massimo: it might not be the correct arch for your rpi Oct 28 09:56:32 I think you'd be better of fixing the recipe, the missing python error is pretty straight forward, you need to depend on python-native, most probably that involves using the meta-python layer, for python2 Oct 28 09:57:24 or you could use a recent version of nodejs that can build with python3 Oct 28 10:02:39 mihai: if i download the pre-compiled tar.gz...and untar directly into /usr/ dir ....it works perfectly Oct 28 10:02:56 mihai: can't understand what appens during the bitbake process Oct 28 10:05:22 Massimo: as LetoThe2nd already stated, poking the binary in the image is not the solution Oct 28 10:08:38 mckoan: understood....i was just wondering what can alter a compiled binary during the bitbake process Oct 28 10:10:10 Massimo: obviously it gets stripped :) Oct 28 10:10:47 "/usr/bin/node: ELF 32-bit LSB executable, ARM, EABI5 version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.26, BuildID[sha1]=cbdb85ab56e5b0f7c31aeb0671fd9b6ae5984f81, with debug_info, not stripped" Oct 28 10:10:50 Massimo: maybe it's a linking issue Oct 28 10:11:38 mihai: as i said...if i download and untar the binaries....everything works....if i "cp" the files from a recipe....not Oct 28 10:11:57 see with ldd Oct 28 10:12:28 maybe you're not shipping everything, maybe some lib from that archive Oct 28 10:12:36 on my yocto i don't have the ldd command....it's the same if i run it on the host machine ? Oct 28 10:14:34 "not a dynamic executable" Oct 28 10:15:40 Massimo: so no :) Oct 28 10:28:28 Massimo: have you prelinking enabled? that might be changing the binary Oct 28 10:28:48 RP how can i check it ? Oct 28 10:30:48 Massimo: is there an entry in your local.conf: USER_CLASSES ?= "buildstats image-mklibs image-prelink" Oct 28 10:33:10 yep...there is Oct 28 10:33:19 image-prelink Oct 28 10:56:54 Massimo: remove that Oct 28 10:58:18 RP: yep i'm just burning the sd Oct 28 11:19:41 RP: you made it!!!!! thank you so much!!! Oct 28 11:32:17 Massimo: no problem. I added an entry to the FAQ section of the manual: http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=master-next&id=21ed84711b7627d52cf8ac18929e89f1d5d78558 Oct 28 11:41:17 at some point we need to unify the FAQ in the manual and the wiki one I've been curating Oct 28 11:41:24 another thing for my todo list... Oct 28 11:41:55 hello, I am attempting to build Qualcomm's u-boot 2016 fork for the IPQ6018 SoC via bitbake (using Yocto 3.2 poky gatesgarth) and failing Oct 28 11:42:12 here is the log: https://pastebin.com/mXxQ69UD Oct 28 11:42:22 bluelightning: that would be a good task to have a bugzilla entry for, someone else might help Oct 28 11:42:53 right, good idea Oct 28 11:42:53 if I enter devshell, do a make mrproper and set CROSS_COMPILE and ARCH environment variables manually, it cross-compiles with Yocto-generated toolchain correctly Oct 28 11:43:07 but not via bitbake and recipe Oct 28 11:44:01 it is weird that there is a line "is not clean, please run 'make mrproper'" in the output Oct 28 11:44:20 any idea how I can even try debugging this? Oct 28 11:44:24 RP: tnx! that helps a lot! in the manual ( section 7.3.21.5. Packaging Externally Produced Binaries ) there is nothing about the pre-linking Oct 28 11:45:30 my u-boot recipe: https://pastebin.com/P6TruQF9 Oct 28 11:47:42 machine configuration: https://pastebin.com/xQYtBBrL Oct 28 11:48:39 ipq-base.inc taken from meta-ipq on codeaurora Oct 28 11:49:29 Massimo: good point, I've added a note to that section too, thanks Oct 28 12:07:56 Good morning Oct 28 12:20:28 thanks a lot for you support, have a good day! Oct 28 12:26:50 moto-timo: you're up early! Oct 28 12:33:07 RP: I have been waking up at 4am for about a week in prep for the conference Oct 28 12:36:19 it would have been more fun if you'd done it the other way. going to bed at 2pm, getting up at 10pm, start drinking and be in perfect conference shape at 4am Oct 28 12:36:48 slightly harder on the day$job Oct 28 12:37:15 why so serious? Oct 28 12:37:50 best time to be awake! Oct 28 13:00:35 if espresso.count === 1 Oct 28 13:23:49 moto-timo: In which timezone are you? Oct 28 13:29:53 Oh man, just found an Older Yocto USB stick from Nov 2010 with Laverne! Must have been from Cambridge, I guess appropriate for the 10 yr anniversary Oct 28 13:41:33 sgw: very appropriate! Oct 28 13:43:46 I thought there might be a way to make bitbake automatically download the buildtools tarball when the build started.... am I making that up? Oct 28 13:44:43 RP: yeah, I have been trying to clean up and reduce my bit-clutter. This one has White lettering on the metal case vs newer ones have the black lettering. Oct 28 13:48:54 sgw: I'm sure there are some around here :) Oct 28 13:49:26 sgw: My day to day one is a mandriva one that predates yocto! Oct 28 13:50:35 manuel1985: pacific... near PDX Oct 28 13:50:48 espresso.count = 2 Oct 28 13:50:55 JPEW: automatically, yes. install-buildtools will fetch/install for you Oct 28 13:51:14 eyelid.weight = 2 metric tonnes Oct 28 13:51:54 moto-timo: who needs expresso when one has scotch ;-( Oct 28 13:52:09 meant ;-) Oct 28 13:54:38 moto-timo and sgw build a "aromatherapy still" in the basement Oct 28 13:55:02 rburton: Ah, Ok. I just have to run the script and source the init. I mis-remembered thinking that it was some bitbake var you could set. Makes sense, thanks :) Oct 28 13:55:10 is it possible to make scotch peat free??? Oct 28 13:55:47 sure, why not? Oct 28 13:55:50 dear lazy web, what's the best practice for setting up bridge networks on the target... post-ints or just a dhcp conf for? Oct 28 13:56:21 I've got xen host and xen guest in the same image, but need to set up the bridge network to have it be fully functional. Oct 28 13:56:41 * moto-timo makes it harder than it should be because networking and brainnzzzzz Oct 28 13:56:41 moto-timo: inject appropriate systemd-network units :) Oct 28 13:56:56 LetoThe2nd: a yes Oct 28 13:57:02 ah Oct 28 13:57:16 * moto-timo has to double check if target is systemd Oct 28 14:10:53 systemd would be my solution for sure Oct 28 14:15:45 yeah, but xen-image-minimal uses SysVInit... but I'll just roll with it Oct 28 14:16:00 systemd networking works really well for use. We basically have one configuration we share with all our devices and use udev rule matching to control which interfaces on different platforms Oct 28 14:16:06 * moto-timo really not awake yet today Oct 28 14:16:43 I'll use systemd in another virt image elsewhere :) Oct 28 14:17:46 * LetoThe2nd hi5es rburton Oct 28 14:18:03 nad yeah, for us systemd-networkd works pretty nicely too. Oct 28 14:18:44 Although, I just had to open a bug in systemd because they broke running weston as a non-root service when you don't have polkit enabled :( Oct 28 14:19:06 https://github.com/systemd/systemd/issues/17473 Oct 28 15:58:58 JPEW: I have a timestamp fix sitting in master-next for the issue we discussed. Seemed to test out ok. Oct 28 15:59:51 * JPEW Looks at RP's patch Oct 28 16:00:57 JPEW: just going with do_package for now Oct 28 16:08:00 RP: Seems reasonable... I guess we don't want hashequive to care about the timestamps if they aren't reproducible in the first place? Oct 28 16:08:14 e.g. BUILD_REPRODUCIBLE_BINARIES == 1 Oct 28 16:09:09 JPEW: right, it doesn't really matter in that case Oct 28 16:15:16 Ok, LGTM Oct 28 16:16:48 JPEW: thanks! Oct 28 16:44:45 how to generate img rootfs? tried hddimg but results in build error. Oct 28 19:29:20 Hello ... can I write a conditional ( if else ) statement in side distro.conf file? Oct 28 19:34:01 kiwi_29: no Oct 28 19:35:51 any other way of using conditions in conf file? Oct 28 19:55:39 kiwi_29: You can use inline pythons: FOO = "${@"a" if d.getVar Oct 28 19:56:03 got it..thats a bit help... JPEW ..thanks Oct 28 19:56:07 kiwi_29: You can use inline pythons: FOO = "${@'a' if d.getVar('BAR') == "1" else 'b'}" Oct 28 19:56:57 Can we add pipenv to crops? Oct 28 20:05:39 Hey all, I am trying to build core-image-minimal but looking at pn-buildlist filtering for non native it seems I have gcc, gcc-cross-, gcc-source- included. I removed debug_tweaks from local.conf but they are still present, how can I avoid building gcc for the target? Oct 28 20:54:34 BWhitten: they are compiled, but not installed to the target image Oct 28 20:55:28 BWhitten: the reason they are compiled is that some of the core items have ptests that need gcc and friends, so when those items are built, all of the dependencies for all supplementary packages need to be built too Oct 28 20:55:45 BWhitten: inspect log.do_rootfs or license manifest to see what actually goes to the image Oct 28 21:00:25 kanavin_home: thanks, so no real way of avoiding building it then. Good to know it wont end up in the image, cheers for the tip on finding what ends up in I was looking for all non native tagged packages Oct 28 21:00:44 kanavin_home: I'm thinking of opening up master and trying to clear the patch backlog. I'm guessing you have something of a patch queue ready? Oct 28 21:01:13 BWhitten: gcc-cross is used to compile things for the target and gcc-source provides the source code for it so those will always be there Oct 28 21:01:38 BWhitten: gcc is on target gcc, turning off ptests if you have those enabled may help reduce the dependencies Oct 28 21:03:44 RP: sure, I was reluctant to send because this week is both ELC-E and trying to get the new release out :) Oct 28 21:03:50 but I can send now Oct 28 21:04:24 kanavin_home: I don't mind adding it to the craziness already queued in -next :) Oct 28 21:04:40 RP: my patchset is perfect! :) Oct 28 21:04:55 (and I can back up that claim, I got all-green from the AB for it) Oct 28 21:05:07 (small print, except for AB-INT issues) Oct 28 21:05:55 kanavin_home: I like perfect patchsets Oct 28 21:06:07 the AB-INT issues are annoying :/ Oct 28 21:06:45 et voila Oct 28 21:06:57 I picked specifically the updates that devtool failed on :) Oct 28 21:07:07 kanavin_home: my email notifications are going suitably crazy :) Oct 28 21:07:26 (except for vulkan updates, because those need new gstreamer, and new gstreamer because it's already been taken care of) Oct 28 21:07:38 kanavin_home: cool, thanks. I've focused on trying to track the patches which usually fall through the cracks in -next so far Oct 28 21:08:02 RP: as long as gstreamer 1.18 is not overlooked, I'm fine Oct 28 21:11:14 kanavin_home: no, they're in now too Oct 28 21:24:42 RP: that sorted it, much better! thanks. Oct 28 21:41:49 khem: fixed optee i think Oct 28 21:46:26 good evening gents, here's an easy one: will EXTRA_IMAGEDEPENDS_remove be honoured when put in an image recipe or is it restricted for use in machine config files? Oct 28 21:57:46 mbulut: the variable is used to create dependencies via anonymous python in image.bbclass, so my guess is that would work in an image recipe Oct 28 22:00:06 mbulut: should work Oct 28 22:13:33 rburton: cool time to update my git submods then lets see Oct 28 22:19:06 RP: where is the patch ? Oct 28 22:19:21 ah that was meant for rburton Oct 28 22:31:52 smurray, RP: thx for confirming Oct 28 22:36:29 khem: should be on the list tomorrow Oct 28 23:46:54 Hello... I am making a container'ized distro ... therefore I have PREFERRED_PROVIDER_virtual/kernel = "linux-dummy" . I have few recipes which compile kernel modules. I would like these to be compiled as part of building containerized distro . When yocto compiles them I get error "make[2]: x86_64-poky-linux-gcc: Command not found" . Could this error be because of using linux-dummy kernel? is there a way to solve it? ie Oct 28 23:46:55 using COMPATIBLE_MACHINE = my_actual_machine_name ? Oct 28 23:59:31 kiwi_29: I don't believe that works, you'll need to specify an actual kernel and not linux-dummy Oct 29 00:01:06 kiwi_29: I'm not sure I understand your usecase, but it's probably workable with an actual kernel recipe, you'll just need to hack your image recipe to remove the unwanted kernel bits Oct 29 00:05:36 based on https://elinux.org/images/6/62/Building-Container-Images-with-OpenEmbedded-and-the-Yocto-Project-Scott-Murray-Konsulko-Group-1.pdf I need to use linux-dummy for perferred virtual/kernel provider Oct 29 00:05:58 I am wondering if that is causing the error for me ? Oct 29 02:33:33 kiwi_29: the issue is what you're seeing, you can't build modules against linux-dummy, as it doesn't build a kernel, so required bits are missing Oct 29 02:34:58 thats true smurray . I m currently building and reproducing the issue . Modules cannot be build against linux-dummy but the error is about non-availability of compiler which looks weird Oct 29 02:36:41 kiwi_29: I believe there is an include makefile deployed by the kernel build that you'll be missing, it wouldn't surprise me if that's causing the failure Oct 29 02:37:23 kiwi_29: and I can't see how you'll get the modules built w/o the kernel tree's headers Oct 29 02:38:48 I thought few days ago I was able to compile it. But I may be mistaken . Is there any way to add COMPATIBLE_MACHINE or such in recipe to still use actual x86_64 architecture based kernel source to compile modules but still use linux-dummy as preferred provider for virtual/kernel? Oct 29 02:39:22 I've no idea, what your attempting doesn't make a lot of sense to me, to be honest Oct 29 02:39:43 any kernel modules inside the container or not, need to be built against the host kernel Oct 29 02:39:54 :) . I know . Its not fully clear. I am waiting for my build to finish ...I will try and report back Oct 29 02:41:37 I think you'll need to do what I suggested earlier if you want to keep on this path, i.e. not use linux-dummy, and instead tweak the image recipe to leave out any unwanted kernel pieces Oct 29 02:42:26 I can imagine some other hacks that involve building the modules as part of the host build in a multiconfig setup, but it'd take some work Oct 29 02:45:44 "multiconfig setup" . I m quite interested in it. I have about 8 different distros that is being generated our of our source. Its a nightmare and I m looking for ways to keep it sane. Any more docs/ideas/information about it please let me know **** ENDING LOGGING AT Thu Oct 29 02:59:57 2020