**** BEGIN LOGGING AT Fri Sep 11 02:59:58 2015 Sep 11 07:14:54 good morning Sep 11 07:23:46 morning. todays quote seen on twitter: debugging is like being the detective in a crime movie where you're also the murderer Sep 11 07:29:44 lol Sep 11 07:34:35 tasslehoff: sometimes the murderer is an hardware engineer though Sep 11 07:35:57 mckoan: true. QA would be the ones that stumble on to the crime scene I guess. Sep 11 07:53:59 khem: hi. sent you a pull request for meta-jetson-tk1, along with a question on one problem with it. Sep 11 08:23:42 Q: I want to create a new version of my patch. How do I do that github/branch-wise? Sep 11 08:24:15 Create a new branch? Delete the old pull request and rewrite the history of the original branch? Sep 11 08:34:06 Nevermind. Sep 11 08:54:08 I'm trying to build yocto/poky master and I ran into a problem with python-lxml_3.4.4.bb which is pulled in as a dependency of something; it fails Sep 11 08:54:11 and the interesting part is Sep 11 08:54:17 Using build configuration of libxml2 0.28 and libxslt 0.28 Sep 11 08:54:17 Minimum required version of libxml2 is 0.28, found 2.7.0 Sep 11 08:54:20 thas what the log says Sep 11 08:54:34 I thought all deps would be built automatically Sep 11 08:54:52 my build host has 2.9 so it's not taking it from there I guess Sep 11 08:55:11 does anyone else have a problem building this package? Sep 11 08:55:59 I also do not see any 2.7.0 recipe anywhere Sep 11 08:56:19 oh.. it may be in the prebuilt toolchain? Sep 11 08:57:23 never mind, I'll upgrade the buildtools toolchain first and check again ;) Sep 11 09:06:02 using buildtools from 1.8 did not help at all :( Sep 11 09:07:36 although maybe I need to wipe tmpdir completely Sep 11 09:22:04 didn't help.. anyone tried building python-lxml-native recently? Sep 11 12:28:58 ok I think I found the bug with the python-lxml native recipe Sep 11 12:29:09 it won't work that way: Sep 11 12:29:10 --with-xslt-config='${STAGING_BINDIR_NATIVE}/pkg-config libxslt' \ Sep 11 12:29:38 because the setupinfo.py checks with --version (thinking that it deals with libxslt-config/libxml2-config), however --version outputs the version of pkg-config Sep 11 12:30:01 --modversion prints the version of the software in question Sep 11 12:38:56 which "component" of OE-Core is meta-openembedded/meta-python? Sep 11 12:39:11 having a hard time to figure out how to submit a bugreport :) Sep 11 12:40:17 or does meta-python has its own bugtracker? Sep 11 12:41:52 moto-timo: ping :) Sep 11 13:00:53 Jin^eLD, send an email to the openembedded list that is the best way to raise issues there Sep 11 13:01:16 Crofton: ok thanks... have to resubscribe then Sep 11 13:01:30 ml's produce constant traffic, so was hoping to drop it in bugzilla Sep 11 13:26:01 | /home/balister/src/oe-core/build/tmp-glibc/work-shared/ettus-e300/kernel-source/include/linux/compiler-gcc.h:106:30: fatal error: linux/compiler-gcc5.h: No such file or directory Sep 11 13:26:10 anyone have an iidea? Sep 11 13:26:51 yes, I had the same Sep 11 13:27:01 that header is supposed to be part of the kernel sources Sep 11 13:27:04 maybe rebase or import it Sep 11 13:27:23 well, depends on which kernel you use, but all 4.x should have it by now Sep 11 13:33:33 this is an older evil vendor kernel Sep 11 13:34:01 * Crofton|work grumbles Sep 11 13:34:27 is the vendor evil or is it the kernel? :) Sep 11 13:35:06 most likely both ;) Sep 11 13:35:20 :) Sep 11 13:35:50 "evil" Sep 11 13:35:51 I am not really good with kernels but from what I understand this header basically defines compiler support, there's one for gcc3, 4 and now 5... Sep 11 13:36:12 I need to hunt the diff Sep 11 13:37:24 hum, you should probably not use gcc5 with an older kernel Sep 11 13:38:30 hum, actually that's fine, gcc6 is more difficult :) Sep 11 16:37:43 Jin^eLD: pong Sep 11 19:30:46 Crofton|work, I didn't find a copy of linux-tools_4.0.2.orig.tar.xz but I can build a fresh one if needed. The checksum of the file would be different but the contents would be essentially the same. Sep 11 21:03:32 halstead, I found one and used it in a local mirrot Sep 11 21:03:53 let me put it in my dropbox and send you an url Sep 11 21:06:47 Crofton|work, sure. When you said oe-core mirror do you mean downloads.yoctoproject.org? sources.openembedded.org doesn't seem to work anymore. Sep 11 21:07:29 ka6sox, ^^^ Sep 11 21:07:44 whatever is in the standard oe-core build mirror path :) Sep 11 21:10:09 Crofton|work, is http://git.openembedded.org/openembedded-core/tree/meta/classes/mirrors.bbclass the standard mirror paths? Sep 11 21:10:25 not 100% certain Sep 11 21:11:54 http://downloads.yoctoproject.org/mirror/sources/ seems to be in th epath Sep 11 21:12:14 in some path :) Sep 11 21:27:48 oe classic, in my SRC_URI I have "http://whatever/foo.zip;unpack=false;name=foo" and later I have SRC_URI[foo.md5sum] = "" and SRC_URI[foo.sha256sum]="" but when I bitbake I get the error "http://whatever/foo.zip cannot check archive integrity". What have I done wrong? Sep 11 21:38:38 that syntax is still correct, afaik. would need more info / the exact log Sep 11 22:14:43 Jin^eLD: send an email to openembedded-devel@lists.openembedded.org with [meta-python] and the package in the subject line Sep 11 22:15:28 Jin^eLD: I will attempt to replicate the error and either patch it myself or give you guidance... Sep 11 22:25:59 halstead, when did this bust? Sep 11 22:26:02 I'll look now Sep 11 22:26:33 ka6sox, I don't know. I hadn't looked at it before. It seems to point at broken sourceforge now. Sep 11 22:31:09 that doesnt' make sense Sep 11 22:31:10 we host that Sep 11 22:31:34 so unless DNS is out to lunch I don't think there is a redirect anywhere. Sep 11 22:41:39 okay should be working Sep 11 22:42:07 ka6sox, Maybe the index was mirrored from sf.net and overwrote incorrectly? Sep 11 23:27:16 an internal autobuilder rsyncs over an internal net to create this from the world builds Sep 11 23:27:52 checking different places this could go wrong. **** ENDING LOGGING AT Sat Sep 12 02:59:58 2015