**** BEGIN LOGGING AT Tue Feb 11 02:59:58 2020 Feb 11 03:36:50 khem, hehe so you out sourced to Canada : ) Feb 11 03:38:01 :) Feb 11 09:48:26 I'm trying to generate an extensible sdk (only used basic sdk till now), and run into different issues: on CI it is instead a failure like https://www.at91.com/viewtopic.php?f=33&t=26235&p=54861 - and on my dev box, where I wanted to investigate that problem, I get instead something ressembling https://gist.github.com/kraj/9ee0302407d29fdf17e7db098256f71e - both occurences according to google appear very rare and without a start of a clue. What could be wrong Feb 11 09:48:26 here ? Feb 11 10:56:17 yann: maybe you could explain your steps till the error, so we could reproduce? Feb 11 10:56:35 i am not sure about your specific error, but maybe while reproducing the setup we could find out Feb 11 11:06:12 creich: it's not really easy because all involved layers are not public - I can try to reproduce with public layers only, though Feb 11 11:09:39 the problem in the CI does not look that hard, so I'm investigating that one remotely first, I'll get to the other one afterwards Feb 11 11:50:20 how can i check what recipe triggers a do_image_wic ? Feb 11 11:52:59 angelo__: probably each recipe that inherits core-image, if your IMAGE_FSTYPES include wic Feb 11 12:22:21 looks like nativesdk-qemu-helper is installed in sdk-ext sysroot when populate_sdk_ext's install_tools get run Feb 11 12:28:28 New news from stackoverflow: Rauc updating fails on Jeton Nano with Yocto/poky Zeus Feb 11 12:57:41 LetoThe2nd, thanks. Can i disable a wik image production from an upper layer ? Feb 11 12:57:52 *wic Feb 11 12:59:05 angelo__: you can set IMAGE_FSTYPES_remove = "wic" Feb 11 12:59:28 eg. at distro level Feb 11 12:59:43 or in a .bbappend for the image Feb 11 13:12:08 yann, ok thanks Feb 11 13:28:38 New news from stackoverflow: CouchDB Replication / Timeout Error Feb 11 14:00:08 creich: so the oe-find-native-sysroot issue is caused by nativesdk-qemu-helper bieing installed, and this comes from inheriting populate_sdk_qt5 in my image .bbclass, via nativesdk-packagegroup-qt5-toolchain-host and nativesdk-packagegroup-sdk-host Feb 11 14:02:20 Does this mean we can't generate a sdk-ext from an image inheriting populate_sdk_qt5 ? I precisely added this to get qt5 support in the basic sdk. What's wrong here ? Feb 11 14:02:45 (using sumo) Feb 11 14:16:17 Hey, I've been wondering, is it possible (and viable) for yocto to build firmwares for bare metal embedded? I've got linux box that has OS built by yocto, and this box has multiple bare metal MCUs connected. I can flash each baremetal using bootloader from this linux box. Can yocto build those bare metal firmwares using other toolchain? E.g. arm-none-gnueabi - i suppose that it should build this bare metal cross toolchain first. Feb 11 14:17:13 kpo: https://twitter.com/TheYoctoJester/status/1222071375864717312 Feb 11 14:17:33 But I'd like to have all modules and linux box at the same git tag, type bitbake everything-image and build everything - from OS to bare metal firmwares. Feb 11 14:18:00 LetoThe2nd: thx :) Feb 11 14:19:20 kpo: basically you want to combine this baremetal approach and https://twitter.com/TheYoctoJester/status/1227134522854080513 Feb 11 14:19:26 kpo: so yes, it can be done. Feb 11 15:31:56 i am getting a very strange error when trying to runqemu a core-image-sato Feb 11 15:31:58 run qemu: Xlib: extension "RANDR" missing on display "localhost:13.0". Feb 11 15:32:25 do you guys know what's going on? Feb 11 15:33:08 you're trying to runqemu on a remote host? Feb 11 15:34:26 localhost:13 suggests that you're SSHing and the error suggests that your local X server is not very good Feb 11 15:34:54 rburton: ++ for politically awesome answer Feb 11 15:36:13 rburton: yes, i am building on a remote host Feb 11 15:38:07 matthewzmd: what is the local machine? Feb 11 15:38:14 * rburton puts money on windows Feb 11 15:38:28 ;) it's manjaro Feb 11 15:41:06 a manjaro kde to be exact Feb 11 15:46:24 qemu over remote X really does suck even if it works, you'll be better to copy the image to your local machine Feb 11 15:57:37 YPTM - armin is on Feb 11 15:57:44 YPTM - Jan-Simon is on Feb 11 15:58:53 YPTM - TrevorW is on Feb 11 15:59:10 YPTM - ScottM is on Feb 11 16:01:19 YPTM notes: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit Feb 11 16:08:59 dreyna: randy is asking about "python2/3" Feb 11 16:13:25 rburton: i re-sshed with -Y flag, it worked ;) Feb 11 16:13:39 dunno why -X causes the problem tho Feb 11 16:14:04 because bits get turned off with just -X Feb 11 16:14:14 (many distros make -Y the default) Feb 11 16:14:36 i see. Feb 11 16:15:28 Stupid question but not clear in docs, site.conf ( with compagny proxy + credentials) should be in build dir or we can put it inside distro folder ? Feb 11 16:18:39 PinkSnake: it can be anywhere Feb 11 16:18:57 rburton thx! Feb 11 16:19:01 PinkSnake: if you have a company layer with your distro in then conf/site.conf in that layer is deal Feb 11 16:19:03 is ideal Feb 11 16:19:37 rburton I will do that, thx for reply ;) Feb 11 16:22:09 YPTM - khem is on Feb 11 16:25:26 YPTM Alejandro just joined Feb 11 16:30:45 tlwoerner: have a link to the page for here? Feb 11 16:31:35 https://wiki.yoctoproject.org/wiki/GSoC/Ideas Feb 11 16:33:13 tlwoerner: thanks Feb 11 16:37:27 JPEW: https://reproducible-builds.org/reports/2020-01/ Feb 11 16:38:38 We had a mention in an earlier newsletter too Feb 11 16:50:07 YPTM- is over Feb 11 16:50:31 what is this YPTM? Feb 11 16:52:52 kpo: Yocto Project Technical Meeting, approximately Feb 11 16:53:58 s/Technical/Team Feb 11 16:56:01 kpo: basically a status update and discussion forum Feb 11 16:57:10 weekly thing, on zoom at https://zoom.us/j/990892712 Feb 11 17:00:06 core-image-sato-sdk-ptest seems to pull in rpm testcases into mix even when rpm is not the package backend any ideas ? Feb 11 17:00:09 https://www.yoctoproject.org/public-virtual-meetings/ Feb 11 17:00:28 Traceback (most recent call last): Feb 11 17:00:30 File "/mnt/b/yoe/sources/openembedded-core/meta/lib/oeqa/core/decorator/__init__.py", line 36, in wrapped_f Feb 11 17:00:32 return func(*args, **kwargs) Feb 11 17:00:34 File "/mnt/b/yoe/sources/openembedded-core/meta/lib/oeqa/runtime/cases/rpm.py", line 31, in test_rpm_query Feb 11 17:00:36 self.assertEqual(status, 0, msg=msg) Feb 11 17:00:38 AssertionError: 1 != 0 : status and output: 1 and package rpm is not installedy Feb 11 17:01:10 is there checkes to see if rpm is installed before it runs ? Feb 11 17:54:31 I thought it only enabled these tests for rpm images Feb 11 17:55:22 RP: seems not to be the case, eg. build core-image-sato-sdk/qemux86-64 with plain OE-Core and you will see the issue Feb 11 17:55:42 khem: doesn't the autobuilder do that though? Feb 11 17:56:13 core-image-sato-sdk-ptest I meant Feb 11 17:56:27 khem: https://autobuilder.yoctoproject.org/typhoon/#/builders/76/builds/1545/steps/8/logs/step1c is sato-sdk with non-rpm Feb 11 17:56:55 sato-sdk works ok its sato-sdk-ptest that fails Feb 11 17:56:55 khem: hmm, the ptest image might be pulling in something that confuses things Feb 11 17:57:04 yeah Feb 11 17:57:35 and another issue I see is Feb 11 17:57:40 AssertionError: None is not true : Some systemd units failed: Feb 11 17:57:42 UNIT LOAD ACTIVE SUB DESCRIPTION Feb 11 17:57:44 ● mdmon@md125.service loaded failed failed MD Metadata Monitor on /dev/md152 Feb 11 17:58:28 which fails systemd.SystemdBasicTests.test_systemd_failed Feb 11 17:58:52 I guess mdadm gets included into core-image-sato-sdk-ptest Feb 11 18:00:25 I was seeing this mdmon@md125.service as well lately Feb 11 18:01:37 is it normal that core-image-sato-ptest-fast takes 2+ hours? Feb 11 18:02:50 JaMa:yes Feb 11 18:03:02 if you are using kvm then its faster Feb 11 18:03:56 I think it will be good to try inserting -smp option to qemu as well to give it more than 1 core, right now it uses 1core+2g-ram Feb 11 18:08:23 RP: opkg->libsolv->rpm thats the dep chain Feb 11 18:08:55 once rpm is pulled in then the selftest checks if rpm is installed on the target and assumes it should run rpm basic tests Feb 11 18:09:20 RP: perhaps it should check for if rpm is not only installed but also has rpm database on target Feb 11 18:28:18 trying this out https://git.openembedded.org/openembedded-core-contrib/commit/?h=yoe/mut&id=21161083a12544b29f23b3756dccb67eaf3dcdde Feb 11 18:29:50 JaMa: are you using kvm? That helps a lot Feb 11 18:50:20 RP: I'm using default poky without any changes (in another try to reproduce the issues you were seeing on autobuilder with my artifacts changes) Feb 11 18:51:45 so I wasn't using kvm Feb 11 18:51:46 grep kvm tmp/work/qemux86_64-poky-linux/core-image-sato-ptest-fast/1.0-r0/temp/log.do_testimage Feb 11 18:51:50 DEBUG: Not using kvm for runqemu Feb 11 18:52:42 trying with QEMU_USE_KVM = 'True' Feb 11 18:52:46 in local.conf now Feb 11 18:56:43 JaMa: we enable that on the autobuilder. You can see the exact config the AB uses in the stdio log FWIW Feb 11 18:56:54 JaMa: its really slow without kvm Feb 11 19:05:26 yes, significantly faster with kvm :) Feb 11 19:05:28 log.core-image-sato-ptest-fast.testimage-2020-02-10:core-image-sato-ptest-fast () - Ran 62 tests in 9568.956s Feb 11 19:05:31 log.core-image-sato-ptest-fast.testimage-2020-02-10:core-image-sato-ptest-fast - OK - All required tests passed (successes=47, skipped=14, failures=0, errors=0) Feb 11 19:05:34 log.core-image-sato-ptest-fast.testimage-2020-02-10b:core-image-sato-ptest-fast () - Ran 62 tests in 467.540s Feb 11 19:05:37 log.core-image-sato-ptest-fast.testimage-2020-02-10b:core-image-sato-ptest-fast - OK - All required tests passed (successes=47, skipped=14, failures=0, errors=0) Feb 11 19:06:02 I've compied the config fragments from autobuilder before to my nodistro build, now I was trying with unmodified poky, that's why I've missed the QEMU_USE_KVM switch Feb 11 20:27:30 I documented by sdk_ext issue in https://github.com/meta-qt5/meta-qt5/issues/284#issuecomment-584833536, as an example of what the missing "how to sdk" doc in meta-qt5 offers, but this still seems to be a poky-level issue, where populate_sdk_ext.bbclass and nativesdk-packagegroup-sdk-host.bb don't play well together, right ? Feb 11 20:29:52 is meta-qt5 doing something wrong here, and how can we do things right instead ? Feb 11 20:32:17 I don't use/support qt5 SDK at all, someone else will need to step in for that Feb 11 20:40:27 well, the essential thing would be for me to gather some insight on sdk inner workings, really :) Feb 11 20:48:03 oh, that issue seems to be fixed in thud, through 2499589fb60ca4fce0b425bc239532378886feb7 - I should have looked first, really Feb 11 21:00:20 RP: https://wiki.yoctoproject.org/wiki/GSoC/Ideas#build_improvements Feb 11 21:18:03 noob here; my recipe builds fine and the 'package' and 'packages-split' directories are being populated with the expected files, but it doesn't generate a .rpm file. I've set PACKAGE_CLASSES ?= "package_rpm". Any ideas? Thanks Feb 11 21:21:57 tlwoerner: I love the " build improvements" subject. I've been thinking for some time that one such improvement would be to add job-server communication between bitbake and do_compile classes, to avoid having as many gnu-make invocations as we have cores, each thinking they have all cores for themselves Feb 11 21:23:52 looks like there is some interest (though little) in adding gnu-make job-server support to ninja - could not find that for meson though Feb 11 21:26:06 yann: you don't like running your machine with a loadavg of 200+? ;-) Feb 11 21:26:51 i.e. multiple bitbake tasks each thinking they have the whole cpu to themselves Feb 11 21:30:09 I don't even tell you about a server with multiple lxc containers, each running one or more gitlab-ci runner, to run the aforementionned bitbake runs :) Feb 11 21:30:34 good parallelism requires good communication :) Feb 11 21:32:32 if you have some interesting build machine, please try to share the build time results in https://github.com/shr-project/test-oe-build-time I hope to get Threadripper 3990x and dual Epyc 7742 server results soon Feb 11 21:38:28 tlwoerner: thanks, I tweaked it a bit Feb 11 21:38:51 RP: excellent, thanks! Feb 11 23:04:38 when bitbake runs, it prints a 'Build Configuration' dumping a lot of version information and so on. is there a way to programmatically access that information, or insert it into the final image? Feb 11 23:11:03 mischief: image-buildinfo class Feb 11 23:15:19 thanks Feb 11 23:25:32 hm do_devshell hangs for some reason on (bitbake -c devshell virtual/kernel) Feb 11 23:50:39 Are you in tmux? Feb 11 23:51:53 Ad0: I think tmux w/ devshell or menuconfig can be troublesome, at least in a past release. If so, try without tmux/screen. Feb 11 23:55:51 ok thanks like2wise Feb 12 01:51:24 like2wise: hey howdy **** ENDING LOGGING AT Wed Feb 12 03:00:33 2020