**** BEGIN LOGGING AT Tue Jan 28 02:59:59 2014
Jan 28 03:17:53 <Crofton|work> ERROR: Fetcher failure: Unable to find revision 6822ec76aa95f278195aeae59d4868ef224d7e4d in branch cross_prelink even from upstream
Jan 28 03:19:49 <nerdboy> does the branch and commit still exist upstream?
Jan 28 03:20:15 <nerdboy> i had a couple libimobiledevice branches just disappear one night...
Jan 28 03:20:21 <Crofton|work> not sure, this is on a new fetch
Jan 28 03:20:29 <nerdboy> like they were never there
Jan 28 03:20:33 <Crofton|work> rebasing that repo would be really anti-social
Jan 28 03:20:50 <nerdboy> the commits appeared on master, but there was no merge commit
Jan 28 03:21:08 <nerdboy> and the branch was just gone
Jan 28 03:21:58 <Crofton|work> weird
Jan 28 03:22:12 <nerdboy> that kind of workflow in public repos baffles me...
Jan 28 03:22:15 <Crofton|work> http://git.yoctoproject.org/cgit/cgit.cgi/prelink-cross/log/?h=cross_prelink
Jan 28 03:22:30 <Crofton|work> it is there
Jan 28 03:22:56 <nerdboy> sure is
Jan 28 03:23:04 <nerdboy> try it again?
Jan 28 03:23:33 <Crofton|work> yeah it is there
Jan 28 03:23:40 <Crofton|work> just checked it out on build machine
Jan 28 03:23:46 <nerdboy> the git fetcher wants to ls-remote all git src_uris at the start of a build
Jan 28 03:24:05 <nerdboy> at least in classic...  i'm assuming that's still the same...
Jan 28 03:24:57 <Crofton|work> I need to chat with some peopl einsidde the network there
Jan 28 03:27:27 <onoffon> Crofton|work: whats is your git version
Jan 28 03:28:13 <khem> http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#required-git-tar-and-python-versions
Jan 28 03:28:29 <khem> if its < 1.7.5 then you are in trouble
Jan 28 03:33:52 <Crofton|work> git version 1.7.7.6
Jan 28 03:33:57 <khem> hmm
Jan 28 03:34:03 <khem> whats  your build host OS
Jan 28 03:34:22 <Crofton|work> F16
Jan 28 03:34:51 <Crofton|work> looks like fischerm will get his wish and build move to "faster machine
Jan 28 03:35:56 <khem> ok show me bitbake -e <image> output
Jan 28 03:36:02 <khem> espeicially ASSUME_PROVIDED
Jan 28 03:37:49 <Crofton|work> loads of stuff
Jan 28 03:37:52 <Crofton|work> grepping
Jan 28 03:37:59 <Crofton|work> may give up and use another machine
Jan 28 03:38:07 <Crofton|work> ASSUME_PROVIDED="bzip2-native chrpath-native git-native grep-native diffstat-native patch-native perl-native-runtime python-native-runtime tar-native virtual/libintl-native "
Jan 28 03:38:57 <Crofton|work> I was hoping to get a little more use out of this machine, but have alrady ad to do some band aiding
Jan 28 03:41:55 <khem> Crofton|work: install the buildtools tarball
Jan 28 03:42:03 <khem> Crofton|work: are you building dora ?
Jan 28 03:42:04 <khem> or master 
Jan 28 03:42:23 <Crofton|work> master
Jan 28 03:42:30 <khem> hmmm ok
Jan 28 03:42:37 <khem> angstrom 
Jan 28 03:42:42 <Crofton|work> I need to be careful with this machine, it builds stuff for product
Jan 28 03:42:54 <khem> ah i see
Jan 28 03:42:55 <Crofton|work> I can try a modern lachine tomorrow
Jan 28 03:43:21 <khem> F16 is old enough 
Jan 28 03:43:22 <Crofton|work> or look into buildtools in a non system dir
Jan 28 03:43:25 <Crofton|work> yeah
Jan 28 03:43:29 <Crofton|work> I need to fall over now
Jan 28 03:43:33 <Crofton|work> thanks for the help
Jan 28 03:43:34 <nerdboy> debian/ubuntu or gentoo-x86 would be my choice
Jan 28 03:43:53 <Crofton|work> I'm not a member of those cults :)
Jan 28 03:44:17 <nerdboy> hopefully gentoo-x86_64/multilib shortly
Jan 28 03:44:30 <khem> what is tar version 
Jan 28 03:46:10 <khem> if its < 1.24 then again you are in trouble
Jan 28 04:07:22 <kergoth> buildtools tarball works pretty well, i use it to do builds on centos5 & centos6. still a couple hiccups, but getting there
Jan 28 04:08:27 <khem`> kergoth: howdy
Jan 28 04:08:33 <kergoth> hey
Jan 28 04:08:34 <khem`> centos5 ?
Jan 28 04:08:55 <khem`> dinosaurs died long ago
Jan 28 04:08:56 <kergoth> its handy when you want run-everywhere native/cross sstates
Jan 28 04:09:48 <kergoth> don't actually try to do much on it, just use a chroot for the build itself
Jan 28 04:11:37 <khem`> hmm
Jan 28 04:12:12 <khem`> I generally use nspawn heavily these days 
Jan 28 04:12:32 <khem`> I have archlinux as base system and then 4 different containers
Jan 28 04:12:49 <khem`> debian/ubuntu/fedora 
Jan 28 04:16:51 <kergoth> nice
Jan 28 04:17:03 <kergoth> one of these days i need to spend more quality time with docker
Jan 28 04:26:53 <nerdboy> okay, here goes nuthin'
Jan 28 04:27:09 <nerdboy> WARNING: Host distribution "Gentoo-n-a" has not been validated ...
Jan 28 04:27:46 <nerdboy> made a multilib pseudo ebuild so this *should* work
Jan 28 04:29:07 <nerdboy> won't know until it gets a little ways into the build tho
Jan 28 04:59:16 <ndec> khem`: how do you use nspawn? do you 'boot' the rootfs with -b? do you configure a user or build as root?
Jan 28 05:00:37 <khem`> ndec:  boot it and add a user
Jan 28 05:00:42 <khem`> we have a write up
Jan 28 05:01:01 <ndec> i have had issues with booting a non systemd rootfs with nspawn.
Jan 28 05:01:09 <ndec> namely debian..
Jan 28 05:01:12 <khem`> http://bec-systems.com/site/1029/os-containers-for-build-systems
Jan 28 05:01:18 <khem`> not at all
Jan 28 05:01:27 <khem`> infact debian/wheezy is my main horse
Jan 28 05:02:05 <ndec> khem`: hmm. well i reported this issue: https://bugs.freedesktop.org/show_bug.cgi?id=68370
Jan 28 05:06:21 <khem`> yes have seen that but creating a  systemd service and on stop it would kill -9 it
Jan 28 05:06:26 <khem`> so got around that
Jan 28 05:08:39 <ndec> khem`: hmm. sorry that was wrong link... that's what I wanted to say: https://bugs.freedesktop.org/show_bug.cgi?id=73935
Jan 28 05:13:22 <khem`> follow our writeup
Jan 28 05:13:25 <khem`> you will be good 
Jan 28 05:17:41 <khem`> ndec: by default it boots into level 5 thats the issue you are seeing
Jan 28 05:17:57 <khem`> you should be good if you booted into run level 3
Jan 28 05:18:14 <khem`> thats what the debian-wheezy.service is doing 
Jan 28 05:18:18 <khem`> if you look at my doc
Jan 28 05:19:01 <ndec> ok, will try again.
Jan 28 05:19:13 <ndec> i might have missed something.
Jan 28 05:19:52 <khem`> I looked at the bug you reported 
Jan 28 05:20:04 <khem`> and it seems your container was booting into level 5
Jan 28 05:23:44 <khem`> another trick I do is add a user with same uid and gid and name as its on arch host 
Jan 28 05:24:01 <khem`> that way I can seemlessly edit files either inside the container or outside
Jan 28 05:24:28 <ndec> khem`: yes, i do that with schroot too. 
Jan 28 05:24:42 <ndec> looking at your page, you don't use -b option to nspawn.
Jan 28 05:24:45 <khem`> debian e.g. has old git and sometimes you might want to use new features e.g. submodule deinit or submodule remote update 
Jan 28 05:25:16 * khem` is sold on systemd
Jan 28 05:25:32 <ndec> ?
Jan 28 05:26:08 <khem`> want to use it everywhere :)
Jan 28 05:26:35 <ndec> same here... 
Jan 28 05:26:48 <ndec> unfortunately, i prefer to use debian for my 'builders'...
Jan 28 05:27:19 <khem`> yeah I do the same although not tied to debian only 
Jan 28 05:29:12 <ndec> khem`: so you confirm that with a command like this one "sudo systemd-nspawn -D /work/chroot/wheezy_x86_64/ --bind /home --bind /work --bind /data/ /sbin/init 3" you are able to build anything in OE? no need to mess up with /dev or /proc?
Jan 28 05:29:39 <ndec> i was under the impression that "-bD" was needed 
Jan 28 05:30:52 <khem`> yes that setup works  fine
Jan 28 05:31:08 <khem`> however I am on archlinux which is uisng systemd 208
Jan 28 05:31:13 <khem`> so that might be a factor 
Jan 28 05:31:20 <khem`> what do you use on base OS ?
Jan 28 05:31:49 <ndec> i am on arch too.
Jan 28 05:32:24 <ndec> i will do some tests.
Jan 28 05:34:08 <khem`> cool
Jan 28 06:11:58 <dv_> khem`: it does have a nice design
Jan 28 06:12:09 <dv_> but what have been the problems with integrating it into oe?
Jan 28 08:22:56 <mckoan> good morning
Jan 28 08:53:19 <bluelightning> morning all
Jan 28 08:56:37 <woglinde> hi bl
Jan 28 08:56:39 <woglinde> hi mckoan
Jan 28 09:00:07 <bluelightning> hi woglinde
Jan 28 09:03:54 <mckoan> hi woglinde, bluelightning, all
Jan 28 11:03:27 <pb_> hi all
Jan 28 11:05:18 <hrw> hi Phil
Jan 28 13:02:45 <Crofton|work> RP, obviously bitbake needs to monitor system performance and adjust threads/-jN dynamically!
Jan 28 13:04:36 <RP> Crofton|work: clearly...
Jan 28 13:04:49 <Crofton|work> bitbake most become self aware
Jan 28 13:05:40 <zecke> it must replace systemd
Jan 28 13:05:46 <Crofton|work> rofl
Jan 28 13:05:47 <Crofton|work> http://people.linaro.org/~rikuvoipio/aarch64-talk/#/8
Jan 28 13:06:02 <Crofton|work> hopefully that is the threads slide :)
Jan 28 14:43:20 * kroon enjoys the backlog
Jan 28 14:53:42 <kroon> i wonder bitbake would even allow a recipe to begin with "+"..
Jan 28 15:11:07 <Crofton|work> http://www.yr.no/place/Belgium/Brussels/Brussels/long.html
Jan 28 15:15:04 <koen> I keep getting confused, is there a tsc meeting today?
Jan 28 15:21:51 <jackmitchell> Crofton|work: better than expected
Jan 28 16:33:30 <bluelightning> koen: don't think so, unless you think we need to call one
Jan 28 17:29:35 <woglinde> hm what was the bitbake command to find out why packages are rebuilded with sstate enabled?
Jan 28 17:30:00 <woglinde> looks like in my setup every bitbake call rebuilds all packages
Jan 28 17:31:14 <kergoth> bitbake-whatchanged
Jan 28 17:33:09 <woglinde> kergoth + the goal?
Jan 28 17:35:25 <kergoth> yeah, bitbake-whatchanged core-image-base
Jan 28 17:35:26 <kergoth> or whatever
Jan 28 17:36:49 <woglinde> hm how the hell rm_work changes?
Jan 28 17:37:25 <woglinde> or populate sysroots
Jan 28 17:37:41 <woglinde> btw. two following calls without config changes
Jan 28 17:37:54 <sr105> how do I get an initramfs image of type cpio.gz.u-boot or equivalent? I can't figure out the proper inherit and IMAGE_FSTYPES settings
Jan 28 17:38:18 <kergoth> woglinde: i usually grep out the Variable changes. otherwise you see every task checksum change down the dep graph
Jan 28 17:38:23 <kergoth> which is of limited usefulness
Jan 28 17:47:08 <sr105> I think I figured it out. Type "u-boot" is silently ignored with no warnings or errors, but cpio.gz.u-boot and cpio.u-boot seem to have worked
Jan 28 17:57:19 <sr105> How do I rebuild a recipe from scratch that has sstate files in an upstream sstate mirror?
Jan 28 17:57:29 <woglinde> ?
Jan 28 17:57:44 <woglinde> -c cleansstate?
Jan 28 17:57:50 <kergoth> cleanssstate wont do it
Jan 28 17:57:53 <kergoth> itll just re-fetch from the mirror
Jan 28 17:57:54 <sr105> That doesn't work upstream
Jan 28 17:58:35 <woglinde> kergoth do you have sstate working at the moment?
Jan 28 17:58:49 <bluelightning> sr105: you'll have to use -f so that the signatures no longer match
Jan 28 17:58:55 <sr105> Or is the moral of the story, don't push state to the mirror unless you're willing to bump PR next time.
Jan 28 17:58:55 <bluelightning> sr105: or -C
Jan 28 17:59:06 <sr105> bluelightning: checking
Jan 28 17:59:09 <bluelightning> sr105: e.g. bitbake -C fetch recipename
Jan 28 17:59:52 <bluelightning> that'll taint the do_fetch signature and force everything else that depends on that task to re-run (up to the default task for the recipe, in that execution)
Jan 28 17:59:54 <woglinde> hm I sill puzzeld
Jan 28 18:00:01 <woglinde> whats going wrong here
Jan 28 18:00:10 <sr105> ah, so if I choose a low enough task in the order to invalidate, it should work.
Jan 28 18:00:36 <bluelightning> sr105: correct... but it doesn't need to be that low, just somewhere before do_populate_sysroot
Jan 28 18:01:03 <bluelightning> woglinde: sstate archive on an external mirror referenced by SSTATE_MIRRORS cannot be deleted by the build system, so -c cleansstate can't help there
Jan 28 18:01:18 <sr105> I haven't applied an OE patch yet that fixes a race condition with INITRAMFS_BUNDLE. This means that if I tweak my kernel, I have to do a cleansstate to get it to build correctly.
Jan 28 18:01:33 <woglinde> bl okay I understood that
Jan 28 18:02:05 <woglinde> bluelightning what could the problem for an image to rebuild everythink? at each bitbake call?
Jan 28 18:02:13 <sr105> Is there a way that I could have the hash of my defconfig factor into the recipe signature?
Jan 28 18:02:36 <kergoth> already happens
Jan 28 18:02:46 <kergoth> any file:// file gets checksummed
Jan 28 18:02:50 <bluelightning> indeed
Jan 28 18:03:11 <sr105> I'll have to figure out what exactly it was that breaks it and then report back.
Jan 28 18:03:22 <bluelightning> woglinde: don't know... which branch are you on?
Jan 28 18:03:28 <woglinde> dora
Jan 28 18:03:35 <woglinde> with archiver stuff backported
Jan 28 18:03:37 <bluelightning> woglinde: latest dora?
Jan 28 18:03:40 <woglinde> and prserver
Jan 28 18:04:04 <sr105> on a related note: what is the purpose/intent of --no-setscene ?
Jan 28 18:04:28 <bluelightning> sr105: mostly debugging I believe
Jan 28 18:04:38 <bluelightning> FWIW I've never used it nor felt any inclination to do so
Jan 28 18:04:50 <sr105> I thought from the help that it might be the solution to my sstate problem.
Jan 28 18:05:29 <kergoth> i've never used it either
Jan 28 18:05:38 <sr105> It rebuilds *everything*
Jan 28 18:05:45 <woglinde> bl I have updated now
Jan 28 18:06:09 <sr105> It implies from the help text that it only builds things that are "needed" skipping sstate.
Jan 28 18:07:04 <kergoth> that sentence doesnt make a great deal of sense. what would be needed and what would be not needed? :)
Jan 28 18:10:07 <woglinde> *sigh* I forgot what do_populate_sysroot_setscene was for
Jan 28 18:10:17 <woglinde> and why it is called at every bitbake call too
Jan 28 18:10:21 <woglinde> or occurs
Jan 28 18:12:18 <kergoth> its what pulls the sstate archive for that task an dunpacks and it all
Jan 28 18:12:22 <kergoth> its run instead of the real task
Jan 28 18:12:22 <bluelightning> woglinde: if it ever gets called, it's because bitbake thinks (a) an item is not in the sysroot (or what's in the sysroot for the recipe isn't the same) and (b) it's been built before so it can be restored from sstate
Jan 28 18:12:24 <sr105> from an end user POV: the only things needed should be the tasks (setscene or runqueue) that would be run without --no-setscene
Jan 28 18:12:49 <kergoth> sr105: the problem is, if a task checksum changes, bitbake rebuilds every task that depends on that task
Jan 28 18:12:54 <kergoth> rippling out through the dependency graph
Jan 28 18:13:07 <kergoth> at least, thats most likely the issue biting you with taht
Jan 28 18:14:04 <sr105> I meant I can run "bitbake recipe; bitbake recipe -c clean; bitbake recipe --no-setscene" and I would expect it only to run the tasks for recipe, but instead it rebuilds everything
Jan 28 18:14:41 <kergoth> i'd just avoid the argument entirely, its of limited usefulness :) but i agree, the semantics of it sound a bit strange
Jan 28 18:14:58 <woglinde> hm but why does it run when I call it twice in a row
Jan 28 18:15:00 <sr105> sorry, wasn't intending to argue. 
Jan 28 18:15:19 <bluelightning> woglinde: is it still doing that now you have updated?
Jan 28 18:15:36 <woglinde> yes
Jan 28 18:15:42 <woglinde> at every bitbake call
Jan 28 18:16:05 <woglinde> maybee the image does something wrong
Jan 28 18:16:46 <bluelightning> woglinde: you have rm_work enabled?
Jan 28 18:17:03 <woglinde> I disabled it
Jan 28 18:17:06 <woglinde> to test
Jan 28 18:17:18 <kergoth> hm
Jan 28 18:18:50 <woglinde> to be sure if I builded qemu-native and do bitbake -c clean qemu-native it should use sstate and not rebuild qemu-native right?
Jan 28 18:19:14 <woglinde> in the next bitbake qemu-native call
Jan 28 18:23:22 <bluelightning> woglinde: correct
Jan 28 18:24:36 <woglinde> okay hm
Jan 28 18:24:53 <woglinde> I tested now with mtd-utils-native
Jan 28 18:25:09 <woglinde> when I do bitbake-whatchanged mtd-utils-native
Jan 28 18:25:44 <woglinde> I always get pkgconfig-native do_populate_sysroot
Jan 28 18:26:03 <woglinde> hm now I did bitbake -c clean pkgconfig-native
Jan 28 18:26:12 <woglinde> hm now I did bitbake -c clean mtd-utils-native
Jan 28 18:26:24 <woglinde> and bitbake mtd-utils-native
Jan 28 18:26:33 <woglinde> mtd-utils-native got rebuilds
Jan 28 18:26:43 <woglinde> and bitbake-whatchanged mtd-utils-native shows
Jan 28 18:26:50 <woglinde> pkgconfig-native: do_fetch do_compile do_patch do_unpack do_configure do_install do_populate_sysroot
Jan 28 18:31:36 <Crofton|work> rburton, thansk for fixing the numpy host include issue :)
Jan 28 18:34:45 <woglinde> hm maybee its the backported archiver stuff trying now
Jan 28 18:37:02 <woglinde> hm looks like the archiver stuff causes the problems
Jan 28 18:38:13 <kergoth> i love the concept of archiver, but i can't say the implementation impresses me too much :(
Jan 28 18:38:42 <bluelightning> kergoth: I'd have to agree
Jan 28 18:39:05 <bluelightning> at least with the most recent changes we're down to a single class
Jan 28 18:39:26 <woglinde> yes but looks like it is not working well with sstate
Jan 28 18:40:22 <Crofton|work> what are the chances of installing qt4 and qt4e in the same rootfs?
Jan 28 18:41:00 <woglinde> but archivr is a needed feature to solve easy the licenses issus
Jan 28 18:41:21 <woglinde> crfoton hm build I think will not work
Jan 28 18:41:29 <woglinde> but installing afterwards could work
Jan 28 18:44:08 <bluelightning> Crofton|work: it should work, but you'll need two sets of apps as well
Jan 28 18:44:33 <kergoth> woglinde: try copyleft_compliance.bbclass. its what we use. it runs regardless of whether sstate is in use, and doesn't disrupt any of the sstate checksums for sure
Jan 28 18:44:51 <Crofton|work> loading a card up with possible demo stuff :)
Jan 28 18:46:17 <woglinde> kergoth class has inherit archiver
Jan 28 18:46:40 <kergoth> woglinde: yes, but it doesn't use it. it just inherits it to use a def'd function
Jan 28 18:46:49 <woglinde> hm okay
Jan 28 18:47:05 <woglinde> will try it
Jan 28 18:47:13 * kergoth wrote copyleft_compliance before archiver existed, and wanted to remove it when archiver came around, but it just wasn't ready for that in his experience
Jan 28 18:47:54 <woglinde> okay
Jan 28 18:49:24 <kergoth> not perfect, but it does the job of giving you license-filtered sources from recipes, for license compliance, which is all we need at the moment
Jan 28 18:49:50 <woglinde> kergoth where does the end up?
Jan 28 18:49:55 <woglinde> are they pachted?
Jan 28 18:50:19 <kergoth> it gives you the as is sources from SRC_URI, tarball+patches, but also includes a series file
Jan 28 18:50:29 <kergoth> license filtered
Jan 28 18:50:32 <woglinde> okay
Jan 28 18:50:38 <woglinde> sounds good
Jan 28 18:51:07 <kergoth> see the COPYLEFT_* variables at the top of archiver.bbclass
Jan 28 18:51:25 <kergoth> default sto just shipping gpl/lgpl sources, and not shiping closed/proprietary
Jan 28 18:51:52 <woglinde> yes that is okay
Jan 28 18:52:14 <kergoth> https://github.com/MentorEmbedded/meta-mentor/blob/master/meta-mel/conf/distro/include/mel.conf#L156-L160 is our slightly more open setup
Jan 28 18:54:13 <zecke> woglinde: okay. it will not archive the patched sources but the original sourcecode + patches and puts them in a dir?
Jan 28 18:54:35 <zecke> from a user point of view it is sad that it worked better in edison than it works dora. :}
Jan 28 18:54:53 <kergoth> thats what copyleft_compliance does. archiver is more flexible, but apparently has other issues
Jan 28 18:57:25 <zecke> kergoth: sources+patches. That is what I figured after reading the bbclass. I backported the archiver to edison (a year ago?) and the nice thing is that a user just needs to unpack and does not need to know the order the patches need to be applied. :)
Jan 28 18:57:30 <woglinde> kergoth do I need to set the archiver confs or is it just to get more licenses in?
Jan 28 18:57:51 <kergoth> woglinde: no need to set the vars unless you want to change the default behavior
Jan 28 18:58:14 <woglinde> okay
Jan 28 18:58:31 <kergoth> there's a new dir in DEPLOY_DIR for its output
Jan 28 18:59:05 <zecke> woglinde: it should include AGPL* too. Most of OpenBSC/Osmocom is AGPL licensed
Jan 28 19:00:10 <zecke> woglinde: so kergoths include/exclude approach is more sane in this regard
Jan 28 19:00:23 <woglinde> yes
Jan 28 19:00:35 <woglinde> we need to exclude the firmware
Jan 28 19:00:45 <kergoth> depends on how paranoid you are, i think, whether source distribution should be opt-in or opt-out :)
Jan 28 19:01:15 <kergoth> what we're really missing now, is license-filtered sstate archive distribution. some of us ship cached binaries, or provide a mirror
Jan 28 19:01:20 <zecke> kergoth: given that archiver.bbclass lacks AGPL* (i assume GPL* doesn't match AGPL..) it is already missing one copyleft license family
Jan 28 19:01:28 * kergoth nods
Jan 28 19:34:27 <woglinde> hm okay copyleft does not work well in multimachine setup
Jan 28 19:34:55 <kergoth> how so?
Jan 28 19:35:54 <woglinde> kernel stuff
Jan 28 19:36:05 <woglinde> deploy/copyleft_sources/linux-sysmocom-3.10.24+gitAUTOINC+1df50cd88f-r31.3/defconfig
Jan 28 19:36:27 <woglinde> only works when kernel versions are diffrent for the machines
Jan 28 19:37:25 <woglinde> okay have to go
Jan 28 19:37:27 <woglinde> till later
Jan 28 19:37:30 <woglinde> maybee
Jan 28 20:33:32 <kroon> the preferred way to create SDK's is using bitbake -c populate_sdk, right ?
Jan 28 20:56:32 <mr_science> kroon: afaik, yes
Jan 28 21:19:22 <kroon> mr_science, mkay, thanks
Jan 28 21:19:54 <Crofton|work> no more making fun of OE voting process: http://lwn.net/Articles/582914/
Jan 28 21:20:19 <Crofton|work> ok, we could have a bad voting proposal
Jan 28 21:27:17 <kroon> i dont get it :-/
Jan 28 21:33:59 <mr_science> kroon: it's a Crofton thing...
Jan 28 21:34:44 <kroon> hehe
Jan 28 21:35:00 <mr_science> but back to the SDK question, the only issues i had running populate_sdk on my rpi image were a few unmet deps
Jan 28 21:38:38 <mr_science> kroon: here's what i did to fix that:  https://github.com/sarnold/meta-alt-desktop-extras/commit/237660e68cb777125058a07c10cc1f60aedeb79f
Jan 28 21:39:05 <Crofton|work> anyone been getting rootfs's with no /sbin/init ?
Jan 28 21:40:00 <kroon> mr_science, ok. i havent seen any problems of that sort myself.. crosses fingers
Jan 28 21:40:08 <mr_science> i've been getting completely whacked rootfs lately...
Jan 28 21:40:18 <Crofton|work> hmm, seems like init is messed up
Jan 28 21:40:28 <mr_science> missing half the dirs from /
Jan 28 21:40:50 <mr_science> the "normal" images with nothing in them build fine
Jan 28 21:41:17 <mr_science> x11-core and rpi-basic anyway...
Jan 28 21:41:35 <mr_science> my own rpi-xorg image is still completely fubared
Jan 28 21:50:33 <Crofton|work> fark
Jan 28 21:50:35 <Crofton|work> ERROR: Fetcher failure: Unable to find file file://glibconfig-sysdefs.h anywhere. The paths that were searched were:
Jan 28 21:52:19 * Crofton|work looks at rburton 
Jan 28 21:52:35 <Crofton|work> I had to go back one commit in oe-core .....
Jan 28 21:53:49 <kroon> my boss just told me I should go to fosdem..
Jan 28 21:53:59 <kroon> does OE have people there ?
Jan 28 21:54:01 * Crofton|work hearts your boos
Jan 28 21:54:04 <Crofton|work> yes
Jan 28 21:54:20 <kroon> cool
Jan 28 21:54:22 <Crofton|work> you can help with the sand :)
Jan 28 21:54:26 <Crofton|work> stand
Jan 28 21:54:31 <Crofton|work> is he paying?
Jan 28 21:54:54 <kroon> yup.. i just wish he would've told me a week ago, so i had a chance to plan :-)
Jan 28 21:55:06 <Crofton|work> where are you?
Jan 28 21:55:12 <kroon> south of sweden
Jan 28 21:55:16 <Crofton|work> ah
Jan 28 21:55:24 <kroon> its a quick ride on the plane though
Jan 28 21:55:29 <Crofton|work> yeah
Jan 28 21:55:45 <Crofton|work> we stay in hotels near the grand place mostly
Jan 28 21:55:55 <Crofton|work> hang on, have you seen our page?
Jan 28 21:56:02 <kroon> no
Jan 28 21:56:09 <mr_science> will your boss pay me to go?
Jan 28 21:56:22 <Crofton|work> http://www.openembedded.org/wiki/FOSDEM_2014
Jan 28 21:56:54 <kroon> mr_science, heh
Jan 28 21:57:13 <mr_science> i could be available for the right price...
Jan 28 21:57:52 <Crofton|work> hopefully that helps some
Jan 28 21:58:52 <Crofton|work> rburton, I'm concerned the pkgconfig patch in oe-core breaks builds
Jan 28 21:59:34 <mr_science> so what's new?  isn't that what pkgconfig is supposed to do?
Jan 28 22:00:59 <kroon> Crofton|work, very cool, i'll see if I can make it. it would be nice to meet some of these IRC names IRL
Jan 28 22:01:40 <Crofton|work> cool
Jan 28 22:01:47 <Crofton|work> if you have questions ask
Jan 28 22:01:59 <Crofton|work> you can take train from airpot into central Brussels
Jan 28 22:02:22 <Crofton|work> I need to do some arm twisting to get more people to help with th estand
Jan 28 22:02:36 <Crofton|work> I'm also involved with the SDR devroom on Sunday
Jan 28 22:12:14 <kroon> dont think I can miss an oppurtunity like this..
Jan 28 22:20:51 <Crofton|work> hmm, I am nmot getting /sbin/init in /sbin anymore
Jan 28 22:20:53 <Crofton|work> wtf
Jan 28 22:21:06 <mr_science> does everything else look normal?
Jan 28 22:21:12 <Crofton|work> yeah
Jan 28 22:21:32 <mr_science> and does your build include systemd or no systemd?
Jan 28 22:21:39 <Crofton|work> -rwsr-xr-- root       shutdown        11152 ./sbin/halt.sysvinit
Jan 28 22:21:39 <Crofton|work> -rwxr-xr-x root       root            34788 ./sbin/hwclock.util-linux
Jan 28 22:21:39 <Crofton|work> -rwxr-xr-x root       root            28668 ./sbin/init.sysvinit
Jan 28 22:21:39 <Crofton|work> lrwxrwxrwx root       root               11 ./sbin/insmod.kmod -> ../bin/kmod
Jan 28 22:21:39 <Crofton|work> -rwxr-xr-x root       root            66532 ./sbin/iwconfig
Jan 28 22:21:45 <Crofton|work> no systemd
Jan 28 22:22:44 <mr_science> looks like all you're missing is the init symlink
Jan 28 22:23:08 <mr_science> admittedly i'm pulling that out of my ass, but...
Jan 28 22:23:20 <Crofton|work> agreed, where does that come from
Jan 28 22:23:31 <mr_science> so maybe the alternative stuff got dorked somehow
Jan 28 22:24:03 <mr_science> alternative "processing" should make that symlink afaik
Jan 28 22:24:28 * mr_science comes largely from a non-alternative distro
Jan 28 22:25:51 * onoffon have used manjaro and it worked out fine with OE
Jan 28 22:27:52 <Crofton|work> hunting
Jan 28 22:28:04 <Crofton|work> by doing core-image minimal builds
Jan 28 22:28:19 <Crofton|work> khem, where does the /sbin/init link come from in images?
Jan 28 22:30:05 <khem`> should be from image.bbclass
Jan 28 22:32:06 <Crofton|work> I am building images with no /sbin/init at the moment :(
Jan 28 22:32:45 <Crofton|work> last change in there was last year
Jan 28 22:32:48 <mr_science> Crofton: what khem said
Jan 28 22:33:06 <mr_science> i told you where i was pulling from...
**** ENDING LOGGING AT Wed Jan 29 02:59:58 2014