**** BEGIN LOGGING AT Mon Jan 05 02:59:58 2015
Jan 05 09:43:37 <bluelightning> morning all
Jan 05 09:44:16 <woglinde> hi bl
Jan 05 09:56:35 <bluelightning> hi woglinde
Jan 05 11:38:05 <pompomJuice> 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 <pompomJuice> cbuild.validation.linaro.org is dead
Jan 05 11:38:58 <pompomJuice> 90% after a ./oebb update linaro fails
Jan 05 11:40:02 <pompomJuice> 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 <pompomJuice> never mind it's our domain server that has old entries for that dns
Jan 05 13:12:27 <kroon> doh. why did updating meta-qt5 trigger a rebuild of "linux-libc-headers-3.17.7-r0"...
Jan 05 13:13:26 <kroon> something is fishy
Jan 05 13:15:29 <kroon> 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 <bluelightning> kroon: you can try looking for linux-libc-headers siginfo files in stamps/ and comparing them with bitbake-diffsigs
Jan 05 13:34:45 <koen> upgrade xz if you want to have some fun
Jan 05 13:35:15 <koen> that will invalidate pretty much every sstate checksum
Jan 05 13:35:15 <koen> "hey look, it rebuilds glibc!"
Jan 05 13:35:19 <pompomJuice> Guys my pseudo_native is not compiling anymore after a change 10Dec2014. 
Jan 05 13:35:19 <pompomJuice> pseudo_ipc.h:67:1: error: unknown type name 'PSEUDO_STATBUF'
Jan 05 13:35:22 <pompomJuice> what can I do
Jan 05 13:35:42 <pompomJuice> but somehow it works on my buildserver
Jan 05 13:36:00 <koen> pompomJuice: which release?
Jan 05 13:36:05 <pompomJuice> 1.6
Jan 05 13:36:21 <koen> I know v2014.06 is broken after the 'stable' updates last month :/
Jan 05 13:36:29 <pompomJuice> oh noes
Jan 05 13:36:33 <pompomJuice> thats not good
Jan 05 13:36:43 <pompomJuice> I cant go to 1.7
Jan 05 13:36:47 <pompomJuice> what are my options?
Jan 05 13:37:28 <koen> not all archs are broken
Jan 05 13:37:28 <koen> from what I can see only some armv5te machines are affected
Jan 05 13:37:28 <pompomJuice> oh ok
Jan 05 13:38:02 <pompomJuice> anyway my pseudo_native wont compile, should I ust nuke the build folder and try again?
Jan 05 13:38:05 <koen> when ant_work returns I'll poke him and see what's broken
Jan 05 13:38:15 <pompomJuice> thanks
Jan 05 13:38:21 <koen> you can try nuking it 
Jan 05 13:38:30 <pompomJuice> ok lets see
Jan 05 13:38:30 <koen> but it could be an update of your host distro breaking it
Jan 05 13:39:12 <kroon> bluelightning, i'll do that
Jan 05 13:39:25 <bluelightning> koen: which update caused the issue ?
Jan 05 13:40:03 <koen> bluelightning: looks like the usual suspect: linux yocto
Jan 05 13:41:07 <koen> 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 <koen> for all meta-handheld machines by the looks of it
Jan 05 13:41:27 <koen> that reminds me, need to try fixing u-boot packaging
Jan 05 13:44:30 <pompomJuice> fixed: doing a cleansstate on pseudo-native did the trick. Bizarre
Jan 05 13:47:21 <bluelightning> koen: doh :(
Jan 05 13:57:54 <JaMa> linux-yocto-tiny-kexecboot got broken in master as well in last few weeks (at least for qemux86-64)
Jan 05 13:58:22 <JaMa> |   Using /home/jenkins/oe/world/shr-core/tmp-glibc/sysroots/qemux86-64/usr/src/kernel as source for kernel
Jan 05 13:58:25 <JaMa> |   /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 <beshelto> 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 <beshelto> Is that what you would expect / would want to see?
Jan 05 17:23:11 <beshelto> Is SRCREV the best way to specify that refpoint, or is there a better way?
Jan 05 17:26:13 <JaMa> beshelto: yes for both questions
Jan 05 17:27:28 <beshelto> JaMa: cool, I'll resubmit with your suggested changes.  Thanks!
Jan 05 17:27:34 <JaMa> 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 <JaMa> beshelto: thanks for contribution and quick responses!
Jan 05 17:31:58 <Crofton|work> Happy New Years guys
Jan 05 17:37:54 <bluelightning> Crofton|work: Happy New Year to you too
Jan 05 17:38:07 <beshelto> Crofton|work: You too!
Jan 05 17:40:13 <JaMa> the same to you all
Jan 05 19:15:11 <Crofton|work> any clues why wget fails with https url?
Jan 05 19:24:22 <broonie> Crofton|work: Self signed certificate problems/
Jan 05 19:24:31 <JaMa> my guess as well
Jan 05 19:24:31 <Crofton|work> hmm
Jan 05 19:24:35 <Crofton|work> ok
Jan 05 19:24:46 <broonie> There was some change in OpenSSL recently which made it much more aggressive with that.
Jan 05 19:24:55 <JaMa> I'm still seeing it with github.com
Jan 05 19:25:09 <Crofton|work> url is wget https://raw.githubusercontent.com/zeromq/cppzmq/master/zmq.hpp
Jan 05 19:25:19 <Crofton|work> works from desktop, not from oe build
Jan 05 19:25:21 <Crofton|work> according to a friend
Jan 05 19:25:39 <JaMa> and wget from Ubuntu-12.04
Jan 05 19:25:46 <Crofton|work> works on Fedora :)
Jan 05 19:29:03 <JaMa> 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 <JaMa> but your link works
Jan 05 19:30:49 <JaMa> OpenSSL: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
Jan 05 19:30:52 <JaMa> Unable to establish SSL connection.
Jan 05 19:48:42 <JaMa> https://www.ssllabs.com/ssltest/analyze.html?d=raw.githubusercontent.com
Jan 05 19:49:05 <JaMa> 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 <Crofton|work> but what does this mean?
Jan 05 19:55:42 <Crofton|work> We see http://pastebin.com/ENfe4NJq
Jan 05 19:55:48 * Crofton|work hunts for an e33
Jan 05 19:55:51 <Crofton|work> e310
Jan 05 19:57:45 <JaMa> was that wget built with ssl support? e.g. does other https sites work?
Jan 05 19:58:28 <Crofton|work> hmm
Jan 05 19:58:37 <Crofton|work> I skiimed recipe and I think so
Jan 05 19:58:41 <Crofton|work> but good thought
Jan 05 19:59:56 <Crofton|work> http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-extended/wget/wget.inc
Jan 05 20:00:00 <Crofton|work> --with-sll=gnutls should get us https support?
Jan 05 20:03:44 <smurray> 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 <Crofton|work> crap
Jan 05 20:04:31 <Crofton|work> I am a moron
Jan 05 20:04:56 <Crofton|work> smurray, I owe you a beer
Jan 05 20:06:41 <smurray> heh
Jan 05 23:54:14 <lansiir> How do I edit the kernel sources without having my changes overwritten every time?
Jan 06 00:02:20 <bencoh> overwritten by ?
Jan 06 00:07:51 <lansiir> bencoh: The build procedure?
Jan 06 00:08:39 <lansiir> 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 <bencoh> it shouldnt overwrite your worktree if you only recompile (bitbake -C compile linux-yocto) ... how did you 
Jan 06 00:09:17 <bencoh> how did you build your kernel after patching it* ?
Jan 06 00:09:36 <bencoh> (hm, afair)
Jan 06 00:09:42 <lansiir> I'm editing the kernel sources in build/tmp/work/edison-poky-linux/linux-yocto/3.10.17+gitAUTOINC+<some checksum>
Jan 06 00:10:23 <bencoh> and how do you run bitbake ?
Jan 06 00:10:31 <lansiir> Just to make sure, this is an openembedded question, right?
Jan 06 00:10:41 <bencoh> yup
Jan 06 00:10:43 <lansiir> "bitbake edison-image"
Jan 06 00:11:06 <bencoh> what if you bitbake -C compile linux-yocto ? does it overwrite everything ?
Jan 06 00:11:27 <bencoh> (If I'm wrong I guess that means I havent patched a kernel in OE for too long :)
Jan 06 00:20:49 <lansiir> bencoh: Alright, lemme repatch, then I'll try that.
Jan 06 00:37:38 <lansiir> 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 <bencoh> bitbake -C menuconfig first maybe (?)
Jan 06 00:40:43 <lansiir> Yeah, it's a lot happier now that I saved it to .config.
Jan 06 00:40:44 <bencoh> or ... there is another task before menuconfig, see listtasks
Jan 06 00:41:11 <lansiir> Isn't the kernel configuration supposed to be stored in device-software/meta-edison/recipes-kernel/linux/files/defconfig?
Jan 06 00:42:08 <bencoh> hmm
Jan 06 00:42:18 <bencoh> I'd say something like linux-yocto/files/
Jan 06 00:42:24 <lansiir> hrm
Jan 06 00:42:27 <bencoh> but I'm not sure
Jan 06 00:43:29 <lansiir> 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 <lansiir> Then since -C compile linux-yocto doesn't rebuild the sources, defconfig is ignored.
Jan 06 00:44:25 <bencoh> .config is generated from defconfig among other things
Jan 06 00:45:57 <lansiir> That would do it then.
Jan 06 00:47:32 <lansiir> How is Yocto related to Openembedded?
Jan 06 01:10:07 <bencoh> yocto is based on openembedded (well, on poky, which is an openembedded implem/flavour, kindof)
Jan 06 01:10:48 <bencoh> and linux-yocto is used as default/generic openembedded linux kernel
Jan 06 01:27:28 <lansiir> Gotcha.
Jan 06 01:28:54 <lansiir> It's compiling now, and the patches/.config changes persist, but the module doesn't get built.
Jan 06 01:29:37 <lansiir> I don't see any mention of the module in the logs in the linux-yocto/<version>/temp directory either.
Jan 06 01:38:25 <lansiir> bencoh: Ideas?
**** ENDING LOGGING AT Tue Jan 06 02:59:59 2015