**** BEGIN LOGGING AT Wed Jun 20 03:00:08 2018 Jun 20 07:13:23 good morning Jun 20 07:13:46 i sometimes get errors because a fully commented line is ending in '\' Jun 20 07:14:08 the error message is also wrong stating that the line is 'partially' commented Jun 20 07:14:20 is this just for me? Jun 20 07:14:42 v2.5 Jun 20 08:09:35 cornel: you can't Jun 20 08:18:59 cornel: no, thats by design. the point is that there's ambiguity between the comment and the \, specifically is the next line a comment? Jun 20 08:19:14 solution: make it an error Jun 20 08:46:58 rburton: no Jun 20 08:47:13 my expectation is that a commented line is ignored Jun 20 08:47:30 and any part of a line after '#' is also ignored Jun 20 08:47:48 to clarify: next line is not a comment Jun 20 08:48:10 i believe yocto/bitbake is trying to hard to prevent user errors in this case :) Jun 20 08:48:18 too hard* Jun 20 09:08:07 hi I'm using meta-boot2qt and when added meta-mender I get a ton of cyclic dependencies but I'm not sure how to debug that like:ERROR: Jun 20 09:08:07 Dependency loop #1 found: Jun 20 09:08:07 Task /home/marek/projects/test/meta-boot2qt/sources/meta-boot2qt/meta-boot2qt/recipes-core/initramfs-basic/initramfs-basic.bb:do_image_complete (dependent Tasks ['qemu-helper-native_1.0.bb:do_populate_sysroot', 'initramfs-basic.bb:do_image_uefiimg', 'initramfs-basic.bb:do_image_mender', 'grub-efi_2.00.bb:do_populate_sysroot', 'initramfs-basic.bb:do_image', 'initramfs-basic.bb:do_image_cpio', 'qemu_2.8.0.bb:do_populate_sysroot', 'ovmf_git.bb Jun 20 09:08:08 :do_populate_sysroot', 'initramfs-basic.bb:do_image_ext4']) Jun 20 09:08:10 Task virtual:native:/home/marek/projects/test/meta-boot2qt/sources/poky/meta/recipes-bsp/grub/grub-efi_2.00.bb:do_install (dependent Tasks ['initramfs-basic.bb:do_image_complete', 'linux-intel_4.9.bb:do_deploy', 'grub-efi_2.00.bb:do_compile']) Jun 20 09:08:14 Task virtual:native:/home/marek/projects/test/meta-boot2qt/sources/poky/meta/recipes-bsp/grub/grub-efi_2.00.bb:do_populate_sysroot (dependent Tasks ['grub-efi_2.00.bb:do_install']) Jun 20 09:08:17 Task /home/marek/projects/test/meta-boot2qt/sources/poky/meta/recipes-core/meta/wic-tools.bb:do_prepare_recipe_sysroot (dependent Tasks ['systemd-boot_232.bb:do_populate_sysroot', 'squashfs-tools_git.bb:do_populate_sysroot', 'gptfdisk_1.0.1.bb:do_populate_sysroot', 'bmap-tools_3.2.bb:do_populate_sysroot', 'mtools_4.0.18.bb:do_populate_sysroot', 'grub-efi_2.00.bb:do_populate_sysroot', 'syslinux_6.03.bb:do_populate_sysroot', 'wic-tools.bb:do_ Jun 20 09:08:24 fetch', 'grub-efi_2.00.bb:do_populate_sysroot', 'btrfs-tools_4.9.1.bb:do_populate_sysroot', 'dosfstools_4.1.bb:do_populate_sysroot', 'parted_3.2.bb:do_populate_sysroot', 'cdrtools-native_3.01.bb:do_populate_sysroot', 'syslinux_6.03.bb:do_populate_sysroot']) Jun 20 09:08:28 Task /home/marek/projects/test/meta-boot2qt/sources/poky/meta/recipes-core/meta/wic-tools.bb:do_configure (dependent Tasks ['wic-tools.bb:do_prepare_recipe_sysroot', 'wic-tools.bb:do_patch']) Jun 20 09:08:31 Task /home/marek/projects/test/meta-boot2qt/sources/poky/meta/recipes-core/meta/wic-tools.bb:do_compile (dependent Tasks ['wic-tools.bb:do_configure']) Jun 20 09:08:34 Task /home/marek/projects/test/meta-boot2qt/sources/poky/meta/recipes-core/meta/wic-tools.bb:do_install (dependent Tasks ['pseudo_1.8.2.bb:do_populate_sysroot', 'wic-tools.bb:do_compile']) Jun 20 09:08:37 Task /home/marek/projects/test/meta-boot2qt/sources/poky/meta/recipes-core/meta/wic-tools.bb:do_populate_sysroot (dependent Tasks ['binutils-cross_2.28.bb:do_populate_sysroot', 'wic-tools.bb:do_install']) Jun 20 09:08:40 Task /home/marek/projects/test/meta-boot2qt/sources/meta-boot2qt/meta-boot2qt/recipes-core/initramfs-basic/initramfs-basic.bb:do_image_uefiimg (dependent Tasks ['gptfdisk_1.0.1.bb:do_populate_sysroot', 'mtools_4.0.18.bb:do_populate_sysroot', 'initramfs-basic.bb:do_rootfs_wicenv', 'wic-tools.bb:do_populate_sysroot', 'grub-efi_2.00.bb:do_deploy', 'initramfs-basic.bb:do_image', 'dosfstools_4.1.bb:do_populate_sysroot']) Jun 20 09:10:23 open-nandra: please use pastebin Jun 20 09:10:33 mckoan os sorry for polluting Jun 20 09:10:56 mckoan: full report is here: https://groups.google.com/a/lists.mender.io/forum/#!topic/mender/T1zoCqP_GIM Jun 20 09:38:37 rburton: I clearly broke it :/ Jun 20 09:38:46 whoops! Jun 20 09:39:07 at least it failed quickly ;) Jun 20 09:48:24 rburton: we'll try that again. Bitbake error reporting there could use some work :/ Jun 20 09:58:34 rburton: clearly not my day today Jun 20 09:58:45 richard! Jun 20 09:59:10 rburton: didn't commit/push the fix properly :/ Jun 20 09:59:27 tsk, i *never* fire a build before actually pushing Jun 20 10:04:52 rburton: oh, I pushed. the commit command didn't quite do what I intended though Jun 20 10:06:56 Has it been discussed/considered saving the temp/ directory alongside the output artifacts in the sstate cache? In order to the the ability to investigate the logs from when the artifact was made. Jun 20 10:09:08 easy enough to write a class to archive the logs Jun 20 10:09:26 sveinse: its an interesting idea. I must admit I've wondered about putting some data into the sstate artefact such as the name of the host it was built on Jun 20 10:09:59 not really the sort of thing you'd put in sstate though surely. sounds more like something you'd throw into a log database Jun 20 10:12:13 RP: my use case is when a system is build repeatedly and continously, and one needs to find the root cause for a regression. Very often I need to dive into logs from packages that have been served from the sstate cache. Jun 20 10:13:33 rburton: you could save it out like we do sigingo Jun 20 10:13:58 sveinse: I get it, I have debugged similar problems. My worry is that temp/ isn't often enough :( Jun 20 10:14:23 e.g. you might need config.log from the build too Jun 20 10:16:15 sveinse: it gets tricky as the logs in temp aren't necessarily from the current build run and there are people who want fast and others who want completeness/logging Jun 20 10:16:38 RP: Yeah, yet looking at temp.do_configure would probably give you enough clues to determine that you'd need to dive into a full rebuild of that recipe to get the config.log. Jun 20 10:16:59 I don't think one needs to go completely overboard on what this delivers, imho Jun 20 10:18:28 Hi, anyone has documentation on different syslog systems? (rsyslog, systemd, syslog-ng, busybox-* ...). Can they forward logs to remote DB? Jun 20 10:19:05 sveinse: Today no, I've just seen the way these things develop. I'm open to conditional code which saved things I guess... Jun 20 10:20:29 RP, I think temp/ needs to be as it is today, even when doing setscenes, since this logging is needed for this purpose. I was more thinking of storing the sstate artifact log files in a separate location where I can find them if I need them Jun 20 10:21:33 sveinse: adding a class which does the log storage shouldn't be too hard... Jun 20 10:21:34 Not even unpack the logs unless explicitly needed. Because you'd only need them if you want to look at them. Jun 20 10:22:00 sveinse: FWIW we handle siginfo/sigdata like this for exactly this reason Jun 20 10:23:00 RP: Yes probably. I don't know bb/oe enough to make one myself thou Jun 20 10:25:48 The challenge is to link the object in the sstate cache with the log record. The sstate cache might contain multiple versions of the same recipe, so it somehow needs to be linked to that hash. And perhaps a symlink needs to be created in the work/temp dir to the log record, since it is hard to know which sstate artifact that has actually been used. Jun 20 10:25:55 sveinse: you could in theory just have a class which appends onto the sstate functions and then saves logs at the same time as the ssate artefacts are generated Jun 20 10:26:22 if you're in the sstate functions, you should have the sstate hash to use Jun 20 10:28:34 If you're a data hoarder and want *everything* you could proably extend this to store the entire workdir when building the recipe and link that to the sstate cache entry Jun 20 10:28:57 that will get very big very fast Jun 20 10:29:03 definitely Jun 20 10:39:32 Hi, folks! Jun 20 10:41:32 I've made SDK with Yocto, but it doesn't work on my target machine because "kernel too old issue". What's the requirements to use SDK generated by Yocto? Jun 20 10:58:38 Guys, I need your help Jun 20 11:03:42 astrunin[m]: see https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#detailed-supported-distros ? Jun 20 11:10:28 nayfe: Is it about populated SDK too? Jun 20 11:21:33 astrunin[m]: don't know, i suppose Jun 20 11:30:55 nayfe: i suppose too. But I have to find clear answer for my boss. Jun 20 11:32:00 Another words: where can I find information about SDKMACHINE requirements? Jun 20 12:12:42 astrunin[m]: maybe ask on ML or wait yocto contributors answer here Jun 20 12:48:18 Is there a reason U-Boot doesn't implement a tftpget command? Jun 20 12:49:02 (other than that nobody has implemented it...) Jun 20 12:50:46 Or am I completely misunderstanding this whole thing.. Jun 20 12:54:27 I see documentation online, and it's also mentioned in the README file, about a plain "tftp" command that reads a file to memory, but it seems to be missing from the code? Has it been deprecated? Jun 20 12:57:30 jof: tftpboot ? Jun 20 12:58:00 nayfe: Almost. Except I'd like it not to boot it. Only fetch a file to memory. Jun 20 12:58:33 That I could then, say, write to QSPI. Jun 20 12:58:47 The seems to be something of the sort going on in pxe.c Jun 20 12:59:17 rburton: all the SDK testing will break on that build :/ Jun 20 13:00:58 Woops! I was actually asking on the wrong channel. Sorry. Jun 20 13:09:00 jof: for me tftpboot is just a way to put something into memory, then you need to bootm; you also have a #u-boot channel on freenode Jun 20 13:09:10 I've run into a problem with the sstate equivalence: what to do with the .siginfo files. It makes sense to me to rename the actual sstate files based on the output hash, but it doesn't make sense to rename the .siginfo files the same way Jun 20 13:59:45 Hello. I tried to build a vmdk image with poky and meta-intel by setting IMAGE_FSTYPES += "wic.vmdk", but it generated just the rootfs.vmdk and misses the boot files. How can I generate a bootable vmdk image? Jun 20 14:00:28 i use the sumo release for both layer Jun 20 14:12:41 Hi Jun 20 14:13:16 Can i ask for a solution or a workaround regarding Yocto here ? Jun 20 14:14:22 karthik_: hi, indeed Jun 20 14:14:37 Super Jun 20 14:15:16 I am new to Yocto and i did a build for an arm platform with Ruby Jun 20 14:15:34 But now i am trying to cross compile some ruby gems for my platform Jun 20 14:15:57 specifically Eventmachine Jun 20 14:16:13 Do anyone here have done that before ? Jun 20 14:16:21 I am struggling with Rakefile Jun 20 14:17:28 can anyone point me to some docs or links where i can use the Ruby which is cross compiled in Yocto to build my gems Jun 20 14:17:29 ? Jun 20 14:27:10 karthik_: not sure why meta-ruby was removed here https://patchwork.openembedded.org/patch/143112/ Jun 20 14:29:39 bfederau_: which WKS do you use? Jun 20 14:35:48 nayfe: Tbh I don't know. Where can I find this? Jun 20 14:36:50 bfederau_: bitbake -e |grep ^WKS_FILE= Jun 20 14:37:36 nayfe: WKS_FILE="systemd-bootdisk-microcode.wks" Jun 20 14:40:00 nayfe: btw I have set MACHINE=intel-corei7-64 Jun 20 14:40:54 bfederau_: not sure be for me, vmdk is for emulated machines, so it doesn't need bootloader? Jun 20 14:45:47 nayfe: well for a virtual machine image you need a bootloader for Linux x86 machines it's grub Jun 20 14:58:58 bfederau_: default intel-corei7-64 uses systemd-boot as bootloader Jun 20 14:59:47 i'm still tying to understand intel world lol :D Jun 20 15:03:53 nayfe: The thing I don't understand is why generates Yocto a rootfs.wic.vmdk file, because a vmdk image file with just the rootfs is not really usable in a virtual machine Jun 20 15:04:14 nayfe: but maybe I do something wrong here :) Jun 20 15:05:11 did you look in logs? did you try to boot it anyway? Jun 20 15:06:21 I get the error "No bootable medium found" when I boot from the vmdk file in the VM Jun 20 15:08:34 and even the file name says that it is the rootfs (core-image-minimal-intel-corei7-64-20180620145422.rootfs.wic.vmdk) Jun 20 15:18:35 bfederau_: if you want to boot in a vm its much easier to use qemux86-64 as a machine type Jun 20 15:20:11 rburton: ok I see. I will try it. But do i have to use the KVM or do you know if I can use the image with VMWare or VBox? Jun 20 15:20:48 You can use it with Virtualbox, at least Jun 20 15:22:00 jof: great. I will try it. Thanks for the info. Jun 20 15:25:52 rburton: any idea why -next broke https://autobuilder.yocto.io/builders/nightly-oe-selftest/builds/1137/steps/Running%20oe-selftest/logs/stdio ? :/ Jun 20 15:31:18 RP: thats something in master isn't it Jun 20 15:31:32 looks like stefan agner's patches Jun 20 15:32:02 rburton: master built ok though? :/ Jun 20 15:36:08 rburton: tests locally say its -next too Jun 20 15:37:29 no then Jun 20 15:39:27 rburton: its my image class change. somehow :/ Jun 20 15:46:57 rburton: its an ordering bug. Horrible. Jun 20 15:59:33 rburton: trying -next again with selftest and sdk fix in Jun 20 16:11:58 New news from stackoverflow: Yocto Project SDK Plug-in does not install for Eclipse Oxygen Jun 20 16:42:12 fray: oh this is weird, sure enough SONAME is right, but the name in the Version Definitions (objdump -x) is wrong. and even if we rebuild oe-core's glibc using their sources and configuration, it's the same issue with the newly produced libc-2.27.so when built by the external binutils+gcc Jun 20 16:42:16 * kergoth scratches head Jun 20 16:42:33 * kergoth tries a different toolchain to make sure he's not completely insane Jun 20 16:43:30 at least you have an explanation.. objdump -x is more accurate if I remember right Jun 20 16:43:54 yeah, now just need to try to figure out how it's produced in the glibc build, wish me luck :) Jun 20 16:43:55 I know a (long while back) the sourcery glibcs had patches that used slightly different versioning then actual glibc.. and the ARM guys replicated that a lot Jun 20 16:44:04 lookf or the .ver files and local changes Jun 20 16:44:05 interesting Jun 20 16:44:08 okay, thanks Jun 20 16:45:05 the odd thing is it occuring with oe-core's glibc recipe/sources/configuration.. i can't imagine how the particulars of how gcc or binutils were built would change glibc's versioning, unless it's pulling something from the crti.o from the external that i'm using to avoid an external -initial recipe.. Jun 20 16:45:11 * kergoth shrugs, back to the grind Jun 20 16:45:40 if it's the same source, I have no idea then.. only thing might be a configure switch that enables/disables specific versioning options Jun 20 16:46:53 same configure args too, it's oe-core's recipe with minor tweaks to avoid the -initial bits and drop external's --sysroot= for crti.o availability Jun 20 16:46:57 not a clue, time for more coffee Jun 20 16:47:03 thanks, just needed to bounce it off of someone else :) Jun 20 16:48:16 at least i know it's nothing to do with rpmdeps now.. figured that was the case, but.. Jun 20 16:55:12 * kergoth rebuilds internal toolchain for comparison Jun 20 17:24:46 http://sarahcandersen.com/post/175076008811 Jun 20 17:24:50 ot, but amusing Jun 20 18:10:29 kanavin_home: I've updated the https://bugzilla.yoctoproject.org/show_bug.cgi?id=9217 a bit Jun 20 18:10:30 Bug 9217: normal, Medium, 2.99, Martin.Jansa, ACCEPTED , Many unsolveable QA warnings from build-deps and file-rdeps Jun 20 18:17:24 JaMa: thanks - like I said I simply do not believe binary paths should be in RDEPENDS at all, so we need a different solution. I'm between jobs now, so can't run experiments. Jun 20 18:20:44 RPROVIDES I mean Jun 20 18:24:41 hm,m could arrange for a way to allow manual alterations of FILERDEPENDS/etc, but the sanity check probably doesn't check those anyway, so maybe not Jun 20 19:19:42 rburton: problem with the xorg upgrades? https://autobuilder.yocto.io/builders/nightly-mips64/builds/1078/steps/Running%20Sanity%20Tests/logs/stdio ? Jun 20 19:19:46 armpit: ^^^? Jun 20 19:20:23 kergoth: I've tried to modify FILERPROVIDES from busybox before, but that didn't work as well (at least in morty where I need to fix this) Jun 20 19:20:41 looks like package.bbclass just sets it rather than appending to it at the moment Jun 20 19:20:58 RP: looks like fbdev isn't happy Jun 20 19:21:16 k Jun 20 19:22:44 I can drop the fbdev upgrade and retry... Jun 20 19:28:13 valgrind isn't building on ppc64be (sumo) Jun 20 19:29:34 looks like similar issue to what ppc-headers.patch is supposed to address Jun 20 19:30:13 complains about implicit declarations for fprintf, stderr, etc. - stuff which is in the standard header files Jun 20 19:31:08 id does build natively on my ppc64be board without any patches though Jun 20 19:36:35 RP, the bind build error is cause by a patch in dhcp, bad thing is the dhcp version we have is going to EOL this month Jun 20 19:36:54 armpit: ah :( Jun 20 19:37:17 I am going to see up the update fixes this issue Jun 20 22:17:29 armpit: I've pushed a customisation mechanism to autobuilder-helper Jun 20 22:24:51 I saw. thanks Jun 20 22:29:57 armpit: its a bit simplistic but as I've just replied to Aaron on the yocto list, I think we can enhance it to be good enough Jun 20 22:48:01 armpit: are you going to push into sumo-next for meta-openembedded Jun 20 22:49:16 yes.. Jun 20 22:55:27 ok Jun 20 22:55:36 I will wait Jun 20 22:55:55 I am setting up release builds on jenkins but there is not enough space Jun 20 22:56:09 may be we can do one release Jun 20 23:08:00 "Exception: TypeError: boolean accepts a string, not ''" Jun 20 23:08:09 gah Jun 20 23:08:20 * kergoth chuckles Jun 20 23:09:18 kergoth: I think its your code ;-) Jun 20 23:09:23 Has anybody seen a do_configure error on openssl while using mingw as SDK_MACHINE Jun 20 23:10:02 kergoth: was trying to do oe.types.boolean(d.getVar("TESTIMAGE_AUTO") or False). Not sure which "fix" I prefer... Jun 20 23:11:34 since december glib is pulling python3 for codegen which because of BBCLASSEXTENDS tries to build nativesdk-python3 which tries to build nativesdk-openssl and it looks like openssl does not support it Jun 20 23:11:34 i expect it should be able to handle a bool *anyway*, but might also change that or False for type consistency Jun 20 23:11:40 so i'd fix it both ways, honestly Jun 20 23:11:42 * kergoth shrugs Jun 20 23:12:34 kergoth: d.getVar("TESTIMAGE_AUTO") or "False" seems a bit ugly somehow but I guess its already messy :( Jun 20 23:15:50 khem, pushed Jun 20 23:19:25 kergoth: I'll fix both... Jun 20 23:20:05 armpit: is it ready ? Jun 20 23:21:04 RP: it might be better to add a fallback ?= or ??= on the variable rather than putting the default there? might look better, anyway Jun 20 23:21:12 i dunno, i'm half asleep Jun 20 23:21:21 caffeine crash Jun 20 23:22:56 kergoth: when you look at the details that doesn't work out as well as I'd like Jun 20 23:23:41 * RP is thoroughly sick of what should have been a simple patch to testimage/testsdk Jun 20 23:30:37 khem, I would not have pushed it, if I didn't think it was. **** ENDING LOGGING AT Thu Jun 21 00:49:12 2018 **** BEGIN LOGGING AT Thu Jun 21 00:49:15 2018 **** ENDING LOGGING AT Thu Jun 21 00:49:15 2018 **** BEGIN LOGGING AT Thu Jun 21 00:58:15 2018 **** ENDING LOGGING AT Thu Jun 21 01:11:42 2018 **** BEGIN LOGGING AT Thu Jun 21 02:42:17 2018 **** ENDING LOGGING AT Thu Jun 21 03:00:01 2018