**** BEGIN LOGGING AT Tue Oct 18 02:59:59 2016 Oct 18 04:06:11 halstead: thanks for looking into the layer index editing issue Oct 18 04:08:26 halstead: btw, I've just pushed a new paule/django18 branch - when you get a chance to look at moving to Django 1.8 please use that. Note that we've added new migrations so just the first time you'll need to use python3 manage.py migrate --fake-initial or the migration will fail Oct 18 04:09:45 Thank you bluelightning. Oct 18 04:09:47 (that's now covered briefly further down in the README, FWIW) Oct 18 04:13:15 bluelightning: I will have to pick this up tomorrow. I also have to drive 2 hours south to work on autobuilders. Busy day ahead. Oct 18 06:59:31 during the building I'm getting an error: linux-kernel do_compile failed Oct 18 07:00:01 What I should look? Oct 18 07:03:34 aV|2: well, how about that very log file that should be mentioned in the error message? Oct 18 07:04:02 LetoThe2nd: it's veeeeery long hahahah Oct 18 07:06:06 aV|2: ok, so.....? Oct 18 07:07:45 there are errors like this: Oct 18 07:08:00 error: redefinition of 'return_address' Oct 18 07:08:00 void *return_address(unsigned int level) Oct 18 07:08:34 And I didn't touch anything Oct 18 07:09:38 I installed the required packages mentioned on the yocto guide, maybe I need something more? Oct 18 07:10:56 aV|2: searching that error message alone is very enlightening. Oct 18 07:11:07 hmm Oct 18 07:14:00 and "I didn't touch anything" is a bout the single most pointless excuse ever. Oct 18 07:14:25 I suspect that you tried to forward the oe/poky version and your kernel can't build with gcc5+ Oct 18 07:16:10 aV|2: https://github.com/gumstix/live-build/issues/5 Oct 18 07:16:19 fl0v0: yeah, saw the same. Oct 18 07:17:03 fl0v0: nice, ty! Oct 18 07:30:13 good morning Oct 18 07:34:11 mckoan: good morning Oct 18 07:34:30 halstead: no worries - hope all goes well with the autobuilder work Oct 18 07:58:13 PNBLACKLIST[apcupsd] ?= "BROKEN: doesn't build with B!=S" what does that actually mean ? Oct 18 07:59:05 bluelightning: around? Oct 18 07:59:28 lpapp: kind of Oct 18 07:59:51 rob_w: doesn't build with build directory separate from the source Oct 18 08:00:39 bluelightning: with the daisy sdk, https://paste.kde.org/pja5ngjkr/gtmgbj/raw Oct 18 08:01:06 rob_w: if you changed inherit autotools to inherit autotools-brokensep it would presumably be able to build Oct 18 08:01:31 bluelightning: this is the brief content of the stdint.h header generated by the Yocto SDK: https://paste.kde.org/pxeqtgimu/i26odn/raw Oct 18 08:02:05 lpapp: not sure I'm afraid Oct 18 08:02:09 bluelightning: worked .. thx .. can you enlight me what exactily brokensep does ? Oct 18 08:02:39 bluelightning: do you have an SDK installed to compare it with your stdint.h? Oct 18 08:03:20 rob_w: basically sets B back to ${S} i.e. builds in the same directory as the source - the default is to do it in a separate directory so that it can be easily cleared out Oct 18 08:03:41 lpapp: not the daisy one Oct 18 08:04:08 right ..got ya , thx Oct 18 08:04:13 bluelightning: any sdk is good to see whether it is very different. Oct 18 08:04:32 bluelightning: because if its content looks saner in newer versions, we have got a problem, I believe. Oct 18 08:05:47 lpapp: so what changed? is this the first time you built this recipe? Oct 18 08:05:54 s/recipe/piece of software/ Oct 18 08:06:24 bluelightning: it is not built from recipe. It is an out of source driver and I am trying to build it with the Yocto SDK for development purposes. Oct 18 08:06:39 as I am doing active work on this out of source tree driver. Oct 18 08:06:56 I thought it was easier to use the SDK than developing it inside Yocto... Oct 18 08:07:00 it builds fine from recipe. Oct 18 08:08:17 lpapp: it's exactly the same FWIW Oct 18 08:08:43 (as the one from an SDK built with master, that is0 Oct 18 08:08:44 ) Oct 18 08:09:18 thank you. Oct 18 08:09:34 bluelightning: can you build a simple main.c that only includes stdint.h with your sDK? Oct 18 08:09:52 #include int main() { return 0; } Oct 18 08:11:16 can i override PNBLACKLIST in a bbappend recipe ? Oct 18 08:21:29 bluelightning: because I can :D Oct 18 08:21:40 so it is not a simple "stdint.h" include problem. Oct 18 08:23:21 bluelightning: oh, one thing I notice in the output: --sysroot=/home/lpapp/Projects/foo/Yocto-daisy-32/src/build/tmp/sysroots/foobar Oct 18 08:23:38 bluelightning: I copied the driver codebase out of the working directory into a separate directory for development Oct 18 08:23:58 I think that messed up things when running make... but apparently, it is still the same sysroot after running ./configure Oct 18 09:03:32 hello I have problems with systemd network and ip addresses ... i defined one static and one dhcp but both are not working Oct 18 09:04:12 cat /lib/systemd/network/10-eth1.network [Match] Name=eth1 [Network] DHCP=yes Oct 18 09:04:51 but he didnt get the correct address from the router Oct 18 09:07:32 RP1: might want to take a look at https://bugzilla.yoctoproject.org/show_bug.cgi?id=10449 Oct 18 09:56:13 hello Oct 18 10:01:17 trying to make very simple experiment with yocto a face a problem. On a clean virtual machine (kubuntu host / kubuntu guest) i have installed yocto toolchain from(http://downloads.yoctoproject.org/releases/yocto/yocto-2.1/toolchain/x86_64/poky-glibc-x86_64-core-image-minimal-armv7a-neon-toolchain-ext-2.1.sh). After sourcing i use it to compile a simple hello world program. I try this exec inside qemu (runqemu qemuarm) using yocto kerne Oct 18 10:01:36 is there a way to use rm_work with exceptions? Oct 18 10:01:46 I need a whitelist. Oct 18 10:01:57 a whitelist for not removing certain things. Oct 18 10:02:15 http://downloads.yoctoproject.org/releases/yocto/yocto-2.1/machines/qemu/qemuarm-lsb/. I face an illegal instruction, looking with gdb it seem's it's in dummy_frame function. What's wrong in my work ? Oct 18 10:15:33 fl0v0: tryied with ubuntu 15.04 which has gcc 4.9 and the build failed again with the same error :( Oct 18 10:16:14 btw, the kernel version thats is trying to build is 3.14.28 Oct 18 10:30:00 I will try with another bsp Oct 18 10:39:13 Any meta-qt5 experts on-line? Oct 18 10:39:42 maybe :) Oct 18 10:39:46 it depends on the question Oct 18 10:43:03 ok. Here is the thingy. I have a bitbake environment up and running and I can built a Linux distro with qt5 included. Now I would like to build my own Qt based application sw but NOT in the bitbake environment. How can I use the qmake and the Qt-libraries which are already in my sysroot to compile my own app without separately installing and configuring a Qt for my host machine? Oct 18 10:44:38 <_icanicant> Can some filesystem folders remove root user's capabilities? We have an app that runs as root/uid=0 but can't make some socket calls or access root's own files when in "/usr/bin", but works fine when the app binary is in "/sbin". Oct 18 10:45:37 LocutusOfBorg: There seems to be something hard coded/configured into the meta-qt5 generated qmake which for some reason does not work when qmake is called outside of bitbake env. Oct 18 10:46:20 muppe, do you want to extract the sdk? Oct 18 10:46:58 what I do to generate it is: Oct 18 10:47:05 assuming your image is foo.bb Oct 18 10:47:10 I create a foo-sdk.bb Oct 18 10:47:13 with this content Oct 18 10:47:38 include foo.bb Oct 18 10:47:45 inherit populate_sdk populate_sdk_qt5 Oct 18 10:47:47 and then I do Oct 18 10:47:54 bitbake -c populate_sdk foo-sdk Oct 18 10:48:07 LocutusOfBorg: not really. Just want to compile apps agains the Qt stuff that already exists in the compiled meta-qt5/bitbake environment without intalling yet another Qt just for doing the same cross-compilation that bitbake does already. Oct 18 10:48:09 this will generate an sdk with qmake and everything you need for your one Oct 18 10:48:44 really Oct 18 10:48:51 that sounds almost too easy :) Oct 18 10:49:18 the reason for sdk to exist is your use-case Oct 18 10:49:25 you extract it in /opt Oct 18 10:49:33 source the environment file, and live happy Oct 18 10:50:08 Awesomeness! I will give it a try. Thanks a lot. Oct 18 10:50:38 :) yw Oct 18 10:51:13 you might want to run qmake with something like Oct 18 10:51:14 QT_SELECT=5 qmake Oct 18 10:51:23 or call the one in opt Oct 18 10:52:41 I'll let you know how it works... Oct 18 10:52:43 I don't even know your OS, I can't help more Oct 18 10:52:52 Linux Ubuntu Oct 18 10:53:01 in case I'm not online, you can find me at mynick@debian.org Oct 18 10:53:06 cross-compiling for raspberry Oct 18 10:53:21 or surnamename@ubuntu.com I guess Oct 18 10:59:17 hello Oct 18 10:59:19 trying to make very simple experiment with yocto a face a problem. On a clean virtual machine (kubuntu host / kubuntu guest) i have installed yocto toolchain from(http://downloads.yoctoproject.org/releases/yocto/yocto-2.1/toolchain/x86_64/poky-glibc-x86_64-core-image-minimal-armv7a-neon-toolchain-ext-2.1.sh). After sourcing i use it to compile a simple hello world program. I try this exec inside qemu (runqemu qemuarm) using yocto kerne Oct 18 10:59:22 http://downloads.yoctoproject.org/releases/yocto/yocto-2.1/machines/qemu/qemuarm-lsb/. I face an illegal instruction, looking with gdb it seem's it's in dummy_frame function. What's wrong in my work ? Oct 18 11:00:26 qemu has no complete implementation of the arm hw Oct 18 11:00:50 not sure, but maybe it isn't your fault Oct 18 11:01:06 what about trying the application on some real hw? so you can know if the process is correct or not Oct 18 11:01:28 as a Ubuntu Developer I use pbuilder-dist yakkety armhf create/login to test some qemu-based arm chroot Oct 18 12:07:36 Hi, I patched a kernel to export a function and booted core-image-minimal and now a kernel module which should make use of that function does not find the symbol. Any ideas what might be wrong here? Oct 18 12:18:40 maho, did you load the kernel modules? usually I don't remember copying them in /lib/modules Oct 18 12:18:45 or the rebuild didn't rebuild everything Oct 18 12:19:03 I have a custom virtual/kernel rebuild to be sure it gets rebuilt correctly Oct 18 12:19:09 with cleanall Oct 18 12:33:06 LocutusOfBorg: Hello again. While the bitbake is still running... does "populate_sdk" create Qt with cross-compile libraries or Qt with host-pc libraries? Or maybe both? (or maybe it is building the whole universe since the bitbake takes so long to run :) ) Oct 18 12:38:06 it needs to build additional software Oct 18 12:38:11 to cross-compile everything Oct 18 12:39:03 ok. I'll try to be patient then. Oct 18 12:50:56 I get these weird warnings.. Oct 18 12:50:56 WARNING: linux-yocto-4.8+gitAUTOINC+03bf3dd731_67813e7efa-r0 do_kernel_configcheck: [kernel config]: specified values did not make it into the kernel's final configuration: Oct 18 12:50:56 ---------- CONFIG_AEABI ----------------- Oct 18 12:50:56 Config: CONFIG_AEABI Oct 18 12:50:56 From: /home/zkakakhel/yocto/poky/build/tmp/work-shared/qemumips32r2el/kernel-source/.kernel-meta/configs/standard/arch/arm/arm.cfg Oct 18 12:50:57 Requested value: CONFIG_AEABI=y Oct 18 12:50:57 Actual value: Oct 18 12:51:17 Wonder why arm.cfg is being applied when I'm only building for mips32r2el Oct 18 12:51:37 Hi guys! Oct 18 12:51:47 I'm trying out qemu. Oct 18 12:51:58 I found the documentation in Yocto. Oct 18 12:52:07 And here I am right now. http://pastebin.com/PXKASwWP Oct 18 12:52:15 ZubairLK, probably you edited it manually Oct 18 12:52:39 present, just build it? Oct 18 12:53:33 I built with MACHINE = raspberrypi2 Oct 18 12:54:01 present: Depending on what you are trying to do, 'slirp' networking might be sufficient. You can add the 'slirp' parameter onto runqemu and it won't use the tun device. Oct 18 12:54:17 present: Otherwise, it tells you to 'bitbake qemu-helper-native'. Oct 18 12:54:30 MACHINEOVERRIDES="rpi:armv7ve:raspberrypi2:lightpixels" Oct 18 12:57:16 zImage-qemuarm.bin doesn't exist with the slirp option Oct 18 12:58:25 +1 for the 'bitbake qemu-helper-native' command Oct 18 12:58:28 getting further Oct 18 12:59:47 Ok I keep having this one: zImage-qemuarm.bin doesn't exist Oct 18 13:04:01 http://pastebin.com/Se1LNT7j Oct 18 13:06:03 I should bitbake my image with MACHINE = qemuarm ? Oct 18 13:06:59 LocutusOfBorg: Now the build is ready. Am I now supposed to source this one: tmp/deploy/sdk/xxxxx-glibc-x86_64-xxxxx-image-sdk-cortexa7hf-vfp-vfpv4-neon-toolchain-2.0.2.sh Oct 18 13:17:03 trying to run bitbake in a docker container, it's acting up a bit though... Oct 18 13:17:22 is there a way to run bitbake without fancy ncurses/color output? Oct 18 13:18:36 Try bitbake -v Oct 18 13:22:40 If someone has idea about qemu. :) I take it! :) Oct 18 13:27:11 muppe, not source ./ Oct 18 13:27:16 it works only with bash Oct 18 13:41:43 * Ulfalizer hopes the container fetish will pass :/ Oct 18 13:41:45 LocutusOfBorg: I managed to install the SDK with sudo sh. After the env init script the qmake works like a charm. Thank you so much for the help. Oct 18 13:44:35 you are welcome Oct 18 13:44:43 sorry for not helping you in the hard way Oct 18 13:45:20 I know how to make it working with the yocto pre-built bitbake directories but you need lots of tweaks, of PATHS, and LD_LIBRARY stuff to make them work Oct 18 13:45:25 SDK makes all of this easy Oct 18 13:45:41 and if you look at the file you source, you can edit to make it work with the current bitbake directory Oct 18 14:09:13 okay so bitbake and docker overlay2 storage driver don't get along it looks like... Oct 18 14:09:23 overlay seems to work better Oct 18 14:47:15 hey, why is -f -c compile not recompiling my source? I put an intentional syntax error into my code, and it does not complain about any compilation error. So, I assume it did not try to build the latest state of the working directory. I just put that syntax error in by going to the working directory and changing the source code in there. Oct 18 14:49:39 lpapp: that'll (re)run the do_compile task at least. make sure you're changing the right source code. Oct 18 14:49:45 and that rebuilding works properly outside of yocto Oct 18 14:50:45 you could run bitbake -e | grep ^B= to check where the build directory is Oct 18 14:51:42 Ulfalizer: yes, I changed the code in B Oct 18 14:51:48 yet. no compilation error Oct 18 14:52:47 hello Oct 18 14:53:21 im working on a tree that for some unknown reason is crapping out during the target buiild of gcc-runtime-5.3.0-r0 Oct 18 14:53:45 its during the do_package and it fails with "Function failed: split_and_strip_files" Oct 18 14:54:21 davis: could try removing tmp/ and rebuilding, though it's kinda like rebooting to fix problems :P Oct 18 14:55:08 https://wiki.yoctoproject.org/wiki/Bug_Triage this page does not show it Oct 18 14:55:22 Ulfalizer: i've tried rebuilding from fresh a few times Oct 18 14:55:27 it keeps hitting this spot Oct 18 14:56:27 I haven't done a system update in months, im kind of hesitant about doing that though Oct 18 14:56:57 my colleague is using archlinux and does not have a problem. i'm on ubuntu 16 Oct 18 15:08:59 davis: no idea off the top of my head Oct 18 15:10:49 yeah me either Oct 18 15:11:09 i see some bug reports which are similar but nothing recently Oct 18 15:11:28 i figured a patch broke something in the last few weeks, apparantly not Oct 18 15:16:14 davis: can you dig further into build tree of gcc-runtime and see if something strikes Oct 18 15:16:50 the info you have doesnt tell much about what could be going wrong. There are several thinks that could be happening Oct 18 15:17:25 wrong use of strip program meant for different arch or some packaging arch Oct 18 15:31:05 khem: i'll look Oct 18 15:32:37 ERROR: debugsrc symlink fixup failed with exit code 512 (cmd was find /home/davis/setup-scripts/build/tmp-glibc/work/corei7-64-oe-linux/gcc-runtime/5.3.0-r0/package/usr/src/debug -type l -print0 -delete | sed s#/home/davis/setup-scripts/build/tmp-glibc/work/corei7-64-oe-linux/gcc-runtime/5.3.0-r0/package/usr/src/debug/##g | (cd '/home/davis/setup-scripts/build/tmp-glibc/work/corei7-64-oe-linux' ; cpio -pd0mL Oct 18 15:32:43 --no-preserve-owner '/home/davis/setup-scripts/build/tmp-glibc/work/corei7-64-oe-linux/gcc-runtime/5.3.0-r0/package/usr/src/debug' 2>/dev/null)). output= Oct 18 15:32:48 that is all that is there Oct 18 15:33:17 all i know is this is during the target build since its corei7 and not x86_64 Oct 18 15:33:32 good day everyone Oct 18 15:33:40 the output line is blank, should that not have something? Oct 18 15:33:47 0x4 hello Oct 18 15:34:41 could somebody help me with symlink to the latest image build? It is not created if everything compiled successfully :-( Oct 18 15:35:06 could gcc-runtime be ok, but something I have done in one of my custom recipes be breaking it? I was thinking not, since my package does not appear to be built yet for the target. Oct 18 15:38:05 I'm giving another try: Someone knows how to launch runqemu with meta-raspberrypi? Oct 18 15:39:23 Basically I have two extension in my build image directory: one *.ext4 and another *.rpi-sdimg Oct 18 15:39:24 ok, this is the fix Oct 18 15:39:53 i had created a link in system /usr/src/debug to my source. i removed that and it now builds. Oct 18 17:24:16 davis: its possible its on your end Oct 18 17:24:29 davis: ok pilot error :) Oct 18 18:02:40 yocoto with fpga based rpis, anyone? Oct 18 18:42:00 khem: yes, my error Oct 18 19:38:29 Hi again! :) Oct 18 19:44:34 present: How are you attempting to launch qemu? Oct 18 19:45:47 One word of warning is that from my recollection, rpi2 is an armv6 or v7 but the default 'qemuarm' is an armv5. I don't know much about running qemu with a rpi2 image, but you might run into that as an issue. Oct 18 19:46:00 After the build and the source with "runqemu qemuarm lightpixels-image ext4" Oct 18 19:46:24 And that gives which error? Oct 18 19:46:42 It's looking for zImage-qemuarm.bin doesn't exist Oct 18 19:47:00 Right. So it is looking for the kernel image. Oct 18 19:47:09 Are there any other zImages? Oct 18 19:47:20 none Oct 18 19:47:51 There would be some file that fed into creating the rpi-sdimg. Oct 18 19:47:56 Maybe a kernel-*? Oct 18 19:48:07 yes I have one .rpi-sdimg Oct 18 19:48:43 rpi-sdimg is a NAND flash image. It is made of partitions. The different pieces that went into each partition should be in the image directory as well. Oct 18 19:48:47 no kernel* neither Oct 18 19:48:54 For example, your ext4 is a partition in the sdimg file. Oct 18 19:49:17 Can you point me to an 'ls' output/ Oct 18 19:52:00 http://pastebin.com/gsbVsEX8 Oct 18 19:56:36 present: I'm not seeing a kernel image there. I don't think this image is intended to be able to run from inside qemu. You could either look in the lightpixels-20161018093228.tgz file for a kernel image or mount the ext4 in loopback and see if you can find a kernel in there. Oct 18 19:56:50 I still suspect even if you find an image it won't work on qemu. Oct 18 20:03:39 stryx`, what about that? runqemu-extract-sdk Oct 18 20:05:55 I'll build a tar.bz2 and give it a try. Oct 18 20:07:57 stryx`, thanks :) Oct 18 20:14:50 Ok the runqemu-extract-sdk method is still looking for that zImage-qemuarm.bin. Oct 18 20:18:01 present: Right. If you have an alternative kernel image you can set the KERNEL environment variable to point at. Oct 18 20:18:15 present: But otherwise it is looking for a default kernel of zImage-qemuarm.bin Oct 18 20:34:32 is there any plan to update pseudo on krogoth branch, so it can be built on a Debian/stretch host ? Oct 18 20:39:09 yann, you can still give it a try. Oct 18 20:39:40 The warning is only to tell you on which the autobuilder are running somehow. Oct 18 20:40:23 stryx`, I'm trying with ROOTFS and KERNEL set now. Oct 18 20:40:55 present: I mean, package "pseudo" *does* break on current stretch, but build succeeds when I cherry-pick all the updates to that package from morty Oct 18 20:41:28 basically, krogoth as such is not buildable on stretch Oct 18 21:02:14 stryx`, not working yet but thanks :) Oct 18 21:02:26 ciao Oct 18 22:08:46 oe-core rev 68e917aa778742da104c038a6e1ffa789fe95410 to fix ppp buidls with 4.8 kernels breaks builds in other circumstances Oct 18 22:10:25 our builds are all failing now Oct 18 22:11:28 how many kernel versions were tested with this? the only build succeeding for us is qemuarm at the moment Oct 18 22:19:58 kergoth: looking at the YP autobuilder it doesn't seem like we saw any related failures in the last build that included that patch Oct 18 22:20:33 if it's only testing 4.8 kernels, that wouldn't necessarily be indicative of much :) Oct 18 22:20:54 it should be testing 4.4 and/or 4.1 as well, let me confirm Oct 18 22:20:56 kergoth, I'm pretty sure zeddii_home had an issue with headers and ppp on the move to 4.8 and dealt with it... maybe the Jackie commit somehow was out of the loop on that? Oct 18 22:21:07 Looks like the problem is specifically linux-libc-headers, not the actual kernel headers Oct 18 22:21:18 which means it'll break anyone using an external toolchain that wasn't built with a new kernel, afaict Oct 18 22:21:47 * kergoth double checks the ppp recipe Oct 18 22:22:17 yeah, ppp doesn't build with the real kernel sources involved Oct 18 22:23:14 so that explains why the autobuilder is working fine, i'm guessing it doesn't do any external toolchain builds Oct 18 22:23:50 no, it doesn't Oct 18 22:24:19 it did build linux-yocto 4.1 in the LSB builds (not that it's related to LSB, just that we test the LTS/LTSI kernel with that) Oct 18 22:25:16 Guess I'll have to revert it in meta-sourcery for now, until a more compatible option is found. it'll break meta-sourcery use with newer external toolchains, but given how few binary toolchains are available with that new kernel headers, it'll do for the moment. Oct 18 22:27:17 can you file a bug so the issue has visibility? Oct 18 22:27:51 s/can you/would you please/ Oct 18 22:28:20 will do Oct 18 22:28:23 thanks Oct 18 22:28:46 that way it will get picked up when they review whether the release is good to go or not Oct 18 22:38:04 fairly easy to work around, just irritating that it has to be done for some toolchains and not others. i'll see if i can work around it in a different way Oct 18 23:11:09 package "pseudo" *does* break on current stretch, but build succeeds when I cherry-pick all the updates to that package from morty - is there any chance to get an update of pseudo in krogoth ? Oct 19 01:01:14 yann, maybe. krogoth is at 1.75 and morty is at 1.8.1. Log a bug https://bugzilla.yoctoproject.org/ **** ENDING LOGGING AT Wed Oct 19 02:59:58 2016