**** BEGIN LOGGING AT Wed Apr 16 02:59:58 2014
Apr 16 07:03:04 <kroon> morning
Apr 16 08:52:42 <andre_d> Hi. Is there a way (existing script) to extract all effective SRC_URIs from all the recipes executed? I want to autoamtically tag some of our source trees after certain bitbake runs and was thinking of using the information from buildhistory-collect-srcrevs, but I also need the original repository URLs.
Apr 16 08:58:17 <bluelightning> morning all
Apr 16 08:58:36 <koen> hey bluelightning 
Apr 16 08:58:42 <bluelightning> hi koen
Apr 16 09:15:57 <JaMa> morning
Apr 16 09:17:17 <bluelightning> hi JaMa
Apr 16 09:18:55 <koen> hey JaMa 
Apr 16 09:26:18 <JaMa> btw jenkins still busy for next few days: Building recipe: python-elementary (1287/1776)
Apr 16 09:57:02 <mago_> i've managed to build images for 2 ARM targets and one x86 target in the same OE tree. Following the first build, the process is very quick, just as if it is re-using packages somehow. I don't understand how that is possible though, between x86 and arm? I understand that it probably doesn't have to re-download much, and it can probably re-use the native tools.. but still, rebuilding all target packages and toolchain should take quite long. Does this happen?
Apr 16 10:06:22 <ant_work> if the targets share the same ARCH the rebuild is very fast, yes
Apr 16 10:07:07 <ant_work> and as you say no d/l and reuse of the -natives is a big speedup for building other ARCHs
Apr 16 10:09:56 <ant_work> ofc this is valid only for little images
Apr 16 10:22:13 <bluelightning> mago_: did you start from completely clean? or did you do something to clean up a previous build? if the latter, what did you do?
Apr 16 10:56:37 <kroon> JaMa, running the test-dependencies.sh script ?
Apr 16 10:57:59 <mago_> bluelightning, well, i did not clean anything. I just did: MACHINE=first bitbake image .. MACHINE=second bitbake image ... MACHINE=third bitbake image
Apr 16 10:58:19 <bluelightning> mago_: I meant before the first run
Apr 16 10:58:27 <mago_> first run was a completely new tree
Apr 16 10:58:43 <bluelightning> so no sstate-cache then?
Apr 16 11:02:56 <ant_work> I'd say for a core-image-minimal the crosscompiler, eglibc and kernel do take most of buildtime
Apr 16 11:03:05 <mago_> bluelightning, correct
Apr 16 11:03:42 <bluelightning> then those items should have been rebuilt...
Apr 16 11:04:35 <mago_> which items? native tools and more?
Apr 16 11:04:52 <bluelightning> no, the cross-compiler, eglibc and the kernel
Apr 16 11:04:59 <mago_> maybe the target stuff did get rebuilt, im not sure. i was just surprised how fast it completed
Apr 16 11:05:03 <bluelightning> native tools wouldn't need rebuilding
Apr 16 11:05:56 <ant_work> native tols are around 2k tasks iirc
Apr 16 11:06:34 <ant_work> staging them is quick
Apr 16 11:07:15 <JaMa> kroon: yes
Apr 16 11:07:44 <koen> after switching to tmpfs builds pseudo is the largest bottleneck in 1.5, followed by grep and sed
Apr 16 11:07:58 <koen> in 1.6rc pseudo seems to be a lot faster
Apr 16 11:08:10 <mago_> how much ram do you need to build everything in tmpfs? =)
Apr 16 11:08:49 <koen> I keep sysroots on SSD and sources on spinning rust, 32GB is enough for that
Apr 16 11:09:06 <koen> rm_work helps a lot
Apr 16 11:09:19 * koen hugs pigz for making sstate so much faster
Apr 16 11:10:00 <bluelightning> koen: oddly when I compared pre-pigz to post-pigz the difference wasn't significant, but maybe it depends on what kind of storage you are using
Apr 16 11:10:19 <mago_> pigz?
Apr 16 11:10:31 <koen> parallel gzip implementation
Apr 16 11:10:39 <bluelightning> http://zlib.net/pigz/
Apr 16 11:11:42 <koen> bluelightning: after the first machine a lot off sstate and source tarballs are in the fscache
Apr 16 11:11:53 <koen> so uncompressing is not IO limited in that case
Apr 16 11:12:00 <koen> iostat shows zero IO
Apr 16 11:12:11 <koen> I wish tmpfs would show up in iostat
Apr 16 11:12:19 <bluelightning> ah right, in my case I was dropping caches between tests to get the absolute performance change
Apr 16 11:15:43 <koen> in 1.5 enabling thumb2 didn't change PACKAGE_ARCH, in 1.6 it does
Apr 16 11:16:16 <koen> I hate it when a bugfix causes problems, especially when the bugfix does the right thing
Apr 16 11:16:30 <bluelightning> hmm
Apr 16 11:16:39 <bluelightning> can you pinpoint the fix?
Apr 16 11:16:47 <bluelightning> we should note it in the migration docs
Apr 16 11:16:54 <koen> problably in the tune files
Apr 16 11:17:19 <kroon> Would mounting build/tmp-eglibc/work as a tmpfs partition allow me to try that out, building on tmpfs ? Or is there a documented recommended way ?
Apr 16 11:17:47 <koen> 8e88392 feature-arm-thumb: Fix missing t2 suffix for armv7a MACHINEs
Apr 16 11:17:55 <koen> I think that's the one
Apr 16 11:18:35 <bluelightning> right just saw that too
Apr 16 11:19:33 <bluelightning> "be aware that this will rename lots of feeds"
Apr 16 11:19:34 <bluelightning> indeed
Apr 16 11:22:16 <kroon> 18GB of data under "work", and I use rm_work ...
Apr 16 11:24:25 <JaMa> I'm sorry about the t2
Apr 16 11:26:04 <JaMa> btw: packagegroups excluding their deps in signature handler are also causing kernel upgrades to fail in do_rootfs (at least here)
Apr 16 11:26:38 <JaMa> it still had runtime dependency on kernel-(image-)3.10.32* after upgrade to 3.14
Apr 16 11:27:15 <JaMa> in most builds you can be lucky that packagegroup is rebuilt at the same time as kernel upgrade, but sometimes you're not
Apr 16 12:20:05 <bluelightning> JaMa: don't be, it was a correct fix
Apr 16 12:20:56 <bluelightning> JaMa: we need to have a better way of handling those dependencies, hard one way or another is problematic as we've seen
Apr 16 12:57:15 <JaMa> bluelightning: I'm still convinced that "rebuilding" packagegroups as TUNE_PKGARCH is less error prone than assuming that all recipes in RDEPENDS will always stay ABISAFE
Apr 16 13:10:07 <bluelightning> JaMa: and I'm still convinced we should fix the problem properly, or we never will
Apr 16 14:53:55 <afournier> is it possible to disable update.rc.d ?
Apr 16 14:54:44 <kergoth> Doubtful, unless you want to switch to systemd. Why do you want to?
Apr 16 14:55:02 <afournier> I want to switch to upstart, i am trying to make an upstart layer :)
Apr 16 14:55:44 <afournier> INHIBIT_UPDATERCD_BBCLASS
Apr 16 14:55:49 <afournier> might be the solution...
Apr 16 14:56:10 <kergoth> ah, yes, indeed, that does sound promising. i think that's set by systemd.bbclass or something
Apr 16 14:56:19 <kergoth> i stnad corrected :)
Apr 16 14:58:23 <bluelightning> afournier: I think there are already people using upstart with OE out there
Apr 16 14:58:51 <afournier> i did not find any upstart layer but i did not look too hard for it
Apr 16 14:59:03 <bluelightning> yep, it's in meta-webos
Apr 16 14:59:16 <bluelightning> http://layers.openembedded.org/layerindex/branch/master/recipes/?q=upstart
Apr 16 15:00:30 <afournier> thanks for the link
**** ENDING LOGGING AT Thu Apr 17 02:59:58 2014