**** BEGIN LOGGING AT Mon Jan 05 02:59:58 2015 Jan 05 09:43:37 morning all Jan 05 09:44:16 hi bl Jan 05 09:56:35 hi woglinde Jan 05 11:38:05 recipy eglibc_linaro-2.19.bb contains a URL http://cbuild.validation.linaro.org/snapshots/eglibc-${PV}-${RELEASE}.tar.bz2 that is dead. Jan 05 11:38:17 cbuild.validation.linaro.org is dead Jan 05 11:38:58 90% after a ./oebb update linaro fails Jan 05 11:40:02 they always move stuff around and our MS domain server for some bizarre reason cant resolve linaro.org entries, only after entering them into a append list do they work. The rest of the internet is fine. Jan 05 11:41:45 never mind it's our domain server that has old entries for that dns Jan 05 13:12:27 doh. why did updating meta-qt5 trigger a rebuild of "linux-libc-headers-3.17.7-r0"... Jan 05 13:13:26 something is fishy Jan 05 13:15:29 and i remember an earlier occasion where linux-libc-headers would mysteriously rebuild for no reason, related to sstate-cache-management.sh removing stuff it shouldn't Jan 05 13:33:46 kroon: you can try looking for linux-libc-headers siginfo files in stamps/ and comparing them with bitbake-diffsigs Jan 05 13:34:45 upgrade xz if you want to have some fun Jan 05 13:35:15 that will invalidate pretty much every sstate checksum Jan 05 13:35:15 "hey look, it rebuilds glibc!" Jan 05 13:35:19 Guys my pseudo_native is not compiling anymore after a change 10Dec2014. Jan 05 13:35:19 pseudo_ipc.h:67:1: error: unknown type name 'PSEUDO_STATBUF' Jan 05 13:35:22 what can I do Jan 05 13:35:42 but somehow it works on my buildserver Jan 05 13:36:00 pompomJuice: which release? Jan 05 13:36:05 1.6 Jan 05 13:36:21 I know v2014.06 is broken after the 'stable' updates last month :/ Jan 05 13:36:29 oh noes Jan 05 13:36:33 thats not good Jan 05 13:36:43 I cant go to 1.7 Jan 05 13:36:47 what are my options? Jan 05 13:37:28 not all archs are broken Jan 05 13:37:28 from what I can see only some armv5te machines are affected Jan 05 13:37:28 oh ok Jan 05 13:38:02 anyway my pseudo_native wont compile, should I ust nuke the build folder and try again? Jan 05 13:38:05 when ant_work returns I'll poke him and see what's broken Jan 05 13:38:15 thanks Jan 05 13:38:21 you can try nuking it Jan 05 13:38:30 ok lets see Jan 05 13:38:30 but it could be an update of your host distro breaking it Jan 05 13:39:12 bluelightning, i'll do that Jan 05 13:39:25 koen: which update caused the issue ? Jan 05 13:40:03 bluelightning: looks like the usual suspect: linux yocto Jan 05 13:41:07 ERROR: Function failed: do_patch (log file is located at /build/jenkins/angstrom-v2014.06/machine/hx4700/build/tmp-angstrom_v2014_06-eglibc/work/hx4700-angstrom-linux-gnueabi/linux-yocto/3.14.4+gitAUTOINC+183622e809_cb22733185-r0/temp/log.do_patch.29431) Jan 05 13:41:07 for all meta-handheld machines by the looks of it Jan 05 13:41:27 that reminds me, need to try fixing u-boot packaging Jan 05 13:44:30 fixed: doing a cleansstate on pseudo-native did the trick. Bizarre Jan 05 13:47:21 koen: doh :( Jan 05 13:57:54 linux-yocto-tiny-kexecboot got broken in master as well in last few weeks (at least for qemux86-64) Jan 05 13:58:22 | Using /home/jenkins/oe/world/shr-core/tmp-glibc/sysroots/qemux86-64/usr/src/kernel as source for kernel Jan 05 13:58:25 | /home/jenkins/oe/world/shr-core/tmp-glibc/sysroots/qemux86-64/usr/src/kernel is not clean, please run 'make mrproper' Jan 05 17:20:46 JaMa: quick question on your review of my iperf3 recipe. The SRCREV I set does indeed point to the 3.0.10 tag. After renaming the recipe to iperf3_git.bb and setting PV as you said, the .ipk is now called iperf3_3.0.10+gitr0+de420cc741-r0_i586.ipk Jan 05 17:21:08 Is that what you would expect / would want to see? Jan 05 17:23:11 Is SRCREV the best way to specify that refpoint, or is there a better way? Jan 05 17:26:13 beshelto: yes for both questions Jan 05 17:27:28 JaMa: cool, I'll resubmit with your suggested changes. Thanks! Jan 05 17:27:34 beshelto: you can also set tag= in the SRC_URI, but bitbake fetcher will convert that to git sha while parsing (causing unwanted network access) so it's really most reliable way now to set just SRCREV Jan 05 17:28:01 beshelto: thanks for contribution and quick responses! Jan 05 17:31:58 Happy New Years guys Jan 05 17:37:54 Crofton|work: Happy New Year to you too Jan 05 17:38:07 Crofton|work: You too! Jan 05 17:40:13 the same to you all Jan 05 19:15:11 any clues why wget fails with https url? Jan 05 19:24:22 Crofton|work: Self signed certificate problems/ Jan 05 19:24:31 my guess as well Jan 05 19:24:31 hmm Jan 05 19:24:35 ok Jan 05 19:24:46 There was some change in OpenSSL recently which made it much more aggressive with that. Jan 05 19:24:55 I'm still seeing it with github.com Jan 05 19:25:09 url is wget https://raw.githubusercontent.com/zeromq/cppzmq/master/zmq.hpp Jan 05 19:25:19 works from desktop, not from oe build Jan 05 19:25:21 according to a friend Jan 05 19:25:39 and wget from Ubuntu-12.04 Jan 05 19:25:46 works on Fedora :) Jan 05 19:29:03 e.g. wget https://github.com/downloads/isis-project/WebKit/WebKit_0.54s.zip fails in Ubuntu-12.04, works in all newer Jan 05 19:30:13 but your link works Jan 05 19:30:49 OpenSSL: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure Jan 05 19:30:52 Unable to establish SSL connection. Jan 05 19:48:42 https://www.ssllabs.com/ssltest/analyze.html?d=raw.githubusercontent.com Jan 05 19:49:05 less strict than https://www.ssllabs.com/ssltest/analyze.html?d=cloud.github.com&s=54.230.35.204&latest Jan 05 19:51:32 but what does this mean? Jan 05 19:55:42 We see http://pastebin.com/ENfe4NJq Jan 05 19:55:48 * Crofton|work hunts for an e33 Jan 05 19:55:51 e310 Jan 05 19:57:45 was that wget built with ssl support? e.g. does other https sites work? Jan 05 19:58:28 hmm Jan 05 19:58:37 I skiimed recipe and I think so Jan 05 19:58:41 but good thought Jan 05 19:59:56 http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-extended/wget/wget.inc Jan 05 20:00:00 --with-sll=gnutls should get us https support? Jan 05 20:03:44 Crofton|work: is it possibly the busybox wget that's getting picked up? I don't see that error message in wget Jan 05 20:04:17 crap Jan 05 20:04:31 I am a moron Jan 05 20:04:56 smurray, I owe you a beer Jan 05 20:06:41 heh Jan 05 23:54:14 How do I edit the kernel sources without having my changes overwritten every time? Jan 06 00:02:20 overwritten by ? Jan 06 00:07:51 bencoh: The build procedure? Jan 06 00:08:39 I added a module to drivers/video, and edited drivers/video/Kconfig. Everything appeared correctly, but the folder was deleted and recreated (clean) during compilation, and the module is missing from the image. Jan 06 00:09:00 it shouldnt overwrite your worktree if you only recompile (bitbake -C compile linux-yocto) ... how did you Jan 06 00:09:17 how did you build your kernel after patching it* ? Jan 06 00:09:36 (hm, afair) Jan 06 00:09:42 I'm editing the kernel sources in build/tmp/work/edison-poky-linux/linux-yocto/3.10.17+gitAUTOINC+ Jan 06 00:10:23 and how do you run bitbake ? Jan 06 00:10:31 Just to make sure, this is an openembedded question, right? Jan 06 00:10:41 yup Jan 06 00:10:43 "bitbake edison-image" Jan 06 00:11:06 what if you bitbake -C compile linux-yocto ? does it overwrite everything ? Jan 06 00:11:27 (If I'm wrong I guess that means I havent patched a kernel in OE for too long :) Jan 06 00:20:49 bencoh: Alright, lemme repatch, then I'll try that. Jan 06 00:37:38 bencoh: Now it seems to have kept the module, but breaks because it can't notify me about the new option I have? http://hastebin.com/japijuyele Jan 06 00:40:25 bitbake -C menuconfig first maybe (?) Jan 06 00:40:43 Yeah, it's a lot happier now that I saved it to .config. Jan 06 00:40:44 or ... there is another task before menuconfig, see listtasks Jan 06 00:41:11 Isn't the kernel configuration supposed to be stored in device-software/meta-edison/recipes-kernel/linux/files/defconfig? Jan 06 00:42:08 hmm Jan 06 00:42:18 I'd say something like linux-yocto/files/ Jan 06 00:42:24 hrm Jan 06 00:42:27 but I'm not sure Jan 06 00:43:29 Is .config generated from defconfig? That would explain how my previous edits worked, since the kernel was rebuilt from scratch each time. Jan 06 00:44:10 Then since -C compile linux-yocto doesn't rebuild the sources, defconfig is ignored. Jan 06 00:44:25 .config is generated from defconfig among other things Jan 06 00:45:57 That would do it then. Jan 06 00:47:32 How is Yocto related to Openembedded? Jan 06 01:10:07 yocto is based on openembedded (well, on poky, which is an openembedded implem/flavour, kindof) Jan 06 01:10:48 and linux-yocto is used as default/generic openembedded linux kernel Jan 06 01:27:28 Gotcha. Jan 06 01:28:54 It's compiling now, and the patches/.config changes persist, but the module doesn't get built. Jan 06 01:29:37 I don't see any mention of the module in the logs in the linux-yocto//temp directory either. Jan 06 01:38:25 bencoh: Ideas? **** ENDING LOGGING AT Tue Jan 06 02:59:59 2015