**** BEGIN LOGGING AT Tue Apr 19 03:00:00 2016
Apr 19 07:09:03 <mckoan> good morning
Apr 19 08:14:20 <Jin^eLD> mornin
Apr 19 08:14:25 <Jin^eLD> halstead: ping
Apr 19 08:14:48 <Jin^eLD> my bitbake is again hanging for hours with an open connection to yoctoproject
Apr 19 08:15:12 <Jin^eLD> tcp        0      0 CentOS-70-64-minimal:39783 yocto-www.yoctoproject.org:https ESTABLISHED
Apr 19 08:15:28 <Jin^eLD> DEBUG: Testing URL http://bugzilla.yoctoproject.org/report.cgi
Apr 19 08:15:34 <Jin^eLD> this is the last entry in the build log
Apr 19 08:16:50 <Jin^eLD> so first question to the ones who know bitbake - what are those tests and why don't they have a timeout?
Apr 19 08:17:03 <Jin^eLD> I'll submit a bug
Apr 19 08:40:24 <Jin^eLD> halstead: https://bugzilla.yoctoproject.org/show_bug.cgi?id=9483
Apr 19 12:23:19 <davis> is there a channel for talking about usb gadget drivers for usb ethernet on beaglebone?
Apr 19 12:24:46 <Crofton|work> #beagle?
Apr 19 12:24:55 <Crofton|work> or whatever channel that is
Apr 19 12:25:38 <davis> yeah i asked. no hits.
Apr 19 14:45:24 <Crofton|work> WARNING: boost-1.60.0-r0 do_package_qa: QA Issue: /usr/lib/libboost_iostreams.so.1.60.0 contained in package boost-iostreams requires libbz2.so.0, but no providers found in RDEPENDS_boost-iostreams? [file-rdeps]
Apr 19 15:04:23 <rburton> Crofton|work: can't replicate here, is that master or what?
Apr 19 15:05:24 <Crofton|work> yeah, flashed by during a build
Apr 19 15:05:52 <rburton> well boost has a DEPENDS=bzip2
Apr 19 15:06:19 <rburton> oh
Apr 19 15:06:23 <rburton> maybe it failed to actually rebuild
Apr 19 15:06:25 <Crofton|work> REDEPENDS
Apr 19 15:06:33 <rburton> as libbz2 is now libbz2.so.1
Apr 19 15:06:43 <Crofton|work> did a change to RDEPNDS go thrugh
Apr 19 15:07:48 <rburton> tenner says it was a rebuild of boost
Apr 19 15:07:58 <rburton> and it didn't do a clean first
Apr 19 15:08:16 <rburton> can you get the boost configure log?
Apr 19 15:10:08 <Crofton|work> I just saw it flash past :)
Apr 19 15:10:22 <Crofton|work> where does boost hide the real configure log?
Apr 19 15:10:27 <Crofton|work> I git pulled oe-core
Apr 19 15:10:30 <Crofton|work> and rebuilt
Apr 19 15:10:48 <Crofton|work> temp/log_doconfigure isn't useful
Apr 19 15:13:44 <LetoThe2nd> is there a known good / recommended way to install nodejs/npm-based applications into a rootfs? or is it more like, prepare release directory structure externally, and then only have recipe that copies that in so far?
Apr 19 15:16:21 <Crofton|work> rburton, when I get a little time, I'll poke locally
Apr 19 15:17:35 <rburton> oh, boost doesn't even look like makefiles
Apr 19 15:17:51 <rburton> so basically boost needs to do out of tree builds - if jam can even do that - or do a clean before configuring
Apr 19 15:18:04 <rburton> or use rm_work, which helps solve a lot of annoying problems
Apr 19 15:18:58 <rburton> my hypothesis being you did a build of boost with old bzip2, time passed, updated to current master, rebuild. bzip2 rebuild as it should, then boost but boost didn't notice that the soname changed so didn't rebuild itself.
Apr 19 15:19:26 <rburton> this is why autotools defaults to out-of-tree so we can just delete the build tree on rebuild, so nothing can leak between builds
Apr 19 15:20:22 <Crofton|work> sounds reasonable
Apr 19 15:21:21 <kergoth> should start an effort to make more non-autotools packages use separate builddirs. VPATH, etc
Apr 19 15:21:22 <rburton> ah looks like it does the build in a directory names after the machine, so just deleting that might work
Apr 19 15:21:29 <kergoth> doesn't sound like a fun task, though
Apr 19 15:21:32 <kergoth> heh
Apr 19 15:22:15 <rburton> aha
Apr 19 15:22:29 <rburton> BJAM_OPTS has —build-dir=${S}/${TARGET_SYS}e
Apr 19 15:23:03 <kergoth> is perf capturing all of MAKEFLAGS to determine the rebuild? seems odd to have to pass it in EXTRA_OEMAKE
Apr 19 15:23:48 <rburton> kergoth: no idea, that was purely a hunch.  doesn't hurt, but basically the perf build system makes my head hurt
Apr 19 15:23:59 <rburton> Crofton|work: i think i have a fix for boost
Apr 19 15:24:02 <kergoth> heh, that's true of a lot of upstream buildsystems, really..
Apr 19 15:24:20 <rburton> oh totally
Apr 19 15:27:49 <rburton> bloody stupid bjam
Apr 19 15:28:07 <Crofton|work> +1000000000000000
Apr 19 15:28:16 <Crofton|work> Is the comment still i the boost recipe about hat
Apr 19 15:28:29 <rburton> builddir has to be a subdirectory of sourcedir as otherwise it can't find the sources
Apr 19 15:28:36 <kergoth> hah
Apr 19 15:28:40 <kergoth> weird assumption
Apr 19 15:28:43 <rburton> yes, the comment is still there
Apr 19 15:28:52 <rburton> "| Attempted search from /data/poky-master/tmp-glibc/work/corei7-64-poky-linux/boost/1.60.0-r0/build up to the root"
Apr 19 15:30:10 <kergoth> I've been doing world builds to try to check for issues when minimizing global exports, finding some funkiness in some of those meta-oe recipes. I found one where something was explicitly passed in EXTRA_OEMAKE, but the one in the env was overriding that anyway due to make -e (zsh -- it explicitly sets bindir to base_bindir, but the export of bindir overrides that back to /usr/bin ..)
Apr 19 15:30:12 * kergoth rolls eyes
Apr 19 15:30:31 <kergoth> damn world builds are really bloating up my sstate cache, i keep running out of space :|
Apr 19 16:02:50 <rburton> Crofton|work: if i start drinking shortly its all your fault
Apr 19 16:03:11 <Crofton|work> heh
Apr 19 16:03:14 <Crofton|work> I know how that goes
Apr 19 16:03:21 <Crofton|work> bjam rat hole descent?
Apr 19 16:05:39 <rburton> yeah
Apr 19 16:05:42 <Crofton|work> wold you rather I not paste things like that into irc when they go past?
Apr 19 16:05:50 <rburton> well they need to be fixed
Apr 19 16:06:17 <rburton> i'll add a # if you're reading this and are not afraid, run # comment to the top of boost.bb
Apr 19 16:07:18 <kergoth> I feel like we should do something about the fact that qa warnings only show up when building from scratch
Apr 19 16:07:34 <kergoth> i.e. shove the warnings into an sstate package and pull them back out, or something
Apr 19 16:07:54 <kergoth> if i didn't write it down the first time through, it's easy to forget it even existed until the next rebuild from scratch
Apr 19 16:08:34 <Crofton|work> I'm at war with updating some docs
Apr 19 16:08:48 <Crofton|work> and had a build blow differently, wiped tmp and retrying
Apr 19 16:08:54 <Crofton|work> and I think I'll ride
Apr 19 16:09:27 <Crofton|work>  * satisfy_dependencies_for: Cannot satisfy the following dependencies for packagegroup-core-x11-utils-dev:
Apr 19 16:09:27 <Crofton|work>  * 	x11-common (= 0.1-r47) * 
Apr 19 18:41:11 <Jin^eLD> kergoth: is it possible to somehow export dynmic shell variables in a python hook instead of directly from the metadata? I'm referring to what we talked about yesterday
Apr 19 18:41:44 <kergoth> the 'export' statement just sets the export flag
Apr 19 18:41:52 <kergoth> so you can set it programmatically in anonymous python
Apr 19 18:41:58 <kergoth> d.setVarFlag('FOO', 'export', '1')
Apr 19 18:42:19 <Jin^eLD> ah, thats what it does, cool, thank you!
Apr 19 18:44:01 <Jin^eLD> lets say i am setting FOO_machine, that gets evaluated before it is passed to the python func, right?
Apr 19 18:44:18 <Jin^eLD> so that the python function would still just set 'FOO'?
Apr 19 18:44:22 <Jin^eLD> right?
Apr 19 18:45:40 <kergoth> the flag is set on the variable. the variable is FOO
Apr 19 18:45:49 <kergoth> the fact that overrides are used to change its value has nothing to do with the flags
Apr 19 18:45:59 <kergoth> the flag has to be set on FOO if you want FOO exported. how FOO gets its value really doesn't matter
Apr 19 18:46:30 <Jin^eLD> roger that
Apr 19 18:46:34 <Jin^eLD> thank you
Apr 19 18:46:40 <kergoth> np
Apr 19 18:55:04 <davis> wc
Apr 19 19:04:34 <Crofton|work> x11-common-dev is empty now
Apr 19 19:34:00 * Crofton|work curses, building image with dev-pkgs set and x11-common explode
Apr 19 19:35:08 <Crofton|work> hmmm
Apr 19 19:41:01 <Jin^eLD> doh... build hangs again on the url test... really noone is seeing this? https://bugzilla.yoctoproject.org/show_bug.cgi?id=9483
Apr 19 19:45:56 <rburton> Jin^eLD: that's bitbake on startup doing a connectivity check to access that url.  does your machine need special proxies?
Apr 19 19:46:17 <rburton> just set CONNECTIVITY_CHECK_URIS="", or don't use poky, to fix
Apr 19 19:46:30 <Jin^eLD> rburton: no,it does not, and since I use that machine remotely when building and am logged in - I can't see any network problems either
Apr 19 19:46:44 <rburton> (or upgrade to master which uses example.com instead)
Apr 19 19:46:50 <Jin^eLD> oh, thanks, that was easy
Apr 19 19:46:58 <Jin^eLD> it just started to happen randomly since mid last week
Apr 19 19:47:34 <rburton> maybe your centos box has a broken whatevver that isn't handling the redirect, or something
Apr 19 19:48:12 <Jin^eLD> well it has been working reliably and now it just sometimes doesnt anymore
Apr 19 19:48:15 <Jin^eLD> which is strange...
Apr 19 19:48:31 <rburton> it uses the fetcher so that will hit wget
Apr 19 19:48:35 <rburton> try wgeting that url?
Apr 19 19:49:04 <rburton> if you want to debug then adding some debugging in the code around CONNECTIVITY_CHECK_URIS in sanity.bbclass will help
Apr 19 19:49:13 <rburton> ie is the fetcher hanging, add more tracing inside the fetcher
Apr 19 19:49:30 <Jin^eLD> ok
Apr 19 19:49:42 <Jin^eLD> the annoying part was that it hung forever
Apr 19 19:49:56 <rburton> was there a wget process still hanging around
Apr 19 19:49:57 <rburton> ?
Apr 19 19:50:07 <Jin^eLD> not that i can remember
Apr 19 19:50:19 <Jin^eLD> I did a pstree
Apr 19 19:50:23 <Jin^eLD> dont remember a wget tehre
Apr 19 19:50:28 <Jin^eLD> i will check when it happens again
Apr 19 19:50:35 <Jin^eLD> but netstat was showing an established connection
Apr 19 19:51:38 <Jin^eLD> I'd just think that even wget would time out after some time...
Apr 19 20:20:29 <Crofton|work> bluelightning, I pulled oe-core to check some of the fixes and ran into this
Apr 19 20:20:30 <Crofton|work> http://pastebin.com/avtmuzVH
Apr 19 20:20:45 <Crofton|work> I'm not seeing any recent commits that make me suspicious
Apr 19 20:20:53 <Crofton|work> image has dev-pkgs on
Apr 19 20:21:52 <bluelightning> Crofton|work: ok... I'm not sure what would cause that, but I would start by looking at whether that package really does exist, then checking the Packages.gz index, etc.
Apr 19 20:22:10 <Crofton|work> I find it in buildhistory and ipk is there
Apr 19 20:22:12 <Crofton|work> really confusing
Apr 19 20:22:53 <bluelightning> probably a broken index then :/
Apr 19 20:23:01 <bluelightning> how that would come about I don't know
Apr 19 20:23:20 <Crofton|work> hmm
Apr 19 20:23:32 <Crofton|work> I wacked tmp at some point
Apr 19 20:23:37 <Crofton|work> tryiing to get around it
Apr 19 20:24:11 <Crofton|work> where is this index?
Apr 19 20:27:39 <bluelightning> in tmp/deploy/ipk/<arch>
Apr 19 20:27:51 <bluelightning> named Packages*
Apr 19 20:28:03 <Crofton|work> so gets rebuilt if I nuke tmp
Apr 19 20:28:08 <bluelightning> yes
Apr 19 20:28:16 <bluelightning> before outright deleting it could you take a look at it?
Apr 19 20:29:03 <Crofton|work> Package: x11-common-dev
Apr 19 20:29:03 <Crofton|work> Version: 0.1-r47
Apr 19 20:29:03 <Crofton|work> Depends: x11-common (= 0.1-r47)
Apr 19 20:29:31 <Crofton|work> and x11-common exists
Apr 20 00:49:49 <Crofton|work> bluelightning, niked sstate and tmp and same problem
Apr 20 01:03:24 <bluelightning> hmm, strange
Apr 20 01:03:40 <bluelightning> I had occasion to debug opkg behaviour just the other day as it happens
Apr 20 01:03:43 <bluelightning> one moment
Apr 20 01:06:26 <Crofton|work> this is a lots of layers maser build
Apr 20 01:06:35 <Crofton|work> but ran core-image-sato and it blew
Apr 20 01:08:43 <bluelightning> Crofton|work: meta/lib/oe/package_manager.py line 1585 (cmd = "%s %s install %s" % ... )
Apr 20 01:08:59 <bluelightning> add -V4 after "install"
Apr 20 01:09:07 <bluelightning> then run the image build again
Apr 20 01:09:18 <bluelightning> log.do_rootfs should have a load more info in it
Apr 20 01:15:58 <Crofton|work> urg
Apr 20 01:35:01 <bluelightning> Crofton|work: problem?
**** ENDING LOGGING AT Wed Apr 20 02:59:58 2016