**** BEGIN LOGGING AT Tue Sep 30 02:59:58 2014
**** BEGIN LOGGING AT Tue Sep 30 03:37:23 2014
**** BEGIN LOGGING AT Tue Sep 30 03:52:42 2014
**** BEGIN LOGGING AT Tue Sep 30 04:01:58 2014
Sep 30 06:51:48 <mckoan> good morning
Sep 30 08:34:19 <bluelightning> morning all
Sep 30 08:36:48 <mckoan> hi bluelightning 
Sep 30 08:36:54 <bluelightning> hi mckoan
Sep 30 08:41:42 <woglinde> gm bluelightning and mckoan
Sep 30 08:41:50 <bluelightning> hi woglinde
Sep 30 09:31:27 <bencoh> does anything provide "host" in OE ?
Sep 30 09:31:38 <bencoh> (apart from bind)
Sep 30 09:33:03 <bluelightning> I'd be surprised if busybox couldn't be made to if it doesn't already
Sep 30 09:33:13 <bencoh> that's what I thought as well, but ...
Sep 30 09:33:58 <bluelightning> hmm, actually according to its docs, apparently it does not
Sep 30 09:34:04 <bencoh> ;)
Sep 30 09:34:05 <bluelightning> or, cannot
Sep 30 09:34:23 <bencoh> it has no dns resolution capabilities
Sep 30 09:34:38 <bencoh> (apart from libc)
Sep 30 09:35:38 <bencoh> ooh but there is good old nslookup in busybox
Sep 30 10:23:09 <pompomJuice> I just realized that the way I add patches is completely wrong:
Sep 30 10:23:21 <pompomJuice> I do a bitbake foo -c patch
Sep 30 10:23:30 <pompomJuice> quilt new patch bar.patch
Sep 30 10:23:36 <pompomJuice> quilt add somefile.c
Sep 30 10:23:39 <pompomJuice> quilt refresh
Sep 30 10:23:48 <pompomJuice> but then I get the following paths in the patch
Sep 30 10:24:32 <pompomJuice> -- 1.0-r22.orig/repo/.../path/to/src/that/is/patched/somefile.c
Sep 30 10:24:48 <pompomJuice> ++ 1.0-r22/repo/.../path/to/src/that/is/patched/somefile.c
Sep 30 10:24:59 <pompomJuice> that PV & PR
Sep 30 10:25:02 <pompomJuice> in the path
Sep 30 10:25:05 <pompomJuice> what is that
Sep 30 10:25:17 <pompomJuice> how could it ever work since those values change with each new build
Sep 30 10:25:42 <pompomJuice> from where does bitbake expect the paths to be when you add patches
Sep 30 10:25:45 <pompomJuice> from ${S}?
Sep 30 10:26:05 <pompomJuice> or from ${WORKDIR}
Sep 30 10:26:24 <pompomJuice> since the patches folder is located at ${WORKDIR}/patches
Sep 30 10:27:04 <pompomJuice> in the previous example my ${S}="repo"
Sep 30 10:27:08 <bluelightning> one level above the source directory, since patches are effectively applied with -p1 by default
Sep 30 10:27:58 <pompomJuice> can I add patches and specify -p1 somehow?
Sep 30 10:28:28 <pompomJuice> for some reason it's locking in the folder above ${WORKDIR} even
Sep 30 10:28:37 <pompomJuice> and that folder changes with each build
Sep 30 10:28:49 <pompomJuice> or workdir changes
Sep 30 10:28:58 <bluelightning> I've not really used quilt much, I prefer the git-based workflow (which is covered in our manual)
Sep 30 10:29:04 <pompomJuice> aah ok
Sep 30 10:29:07 <pompomJuice> I will go read up on that
Sep 30 10:29:12 <pompomJuice> I am adding my own patches though
Sep 30 10:29:15 <pompomJuice> shit
Sep 30 10:29:19 <pompomJuice> it's been wrong all this time
Sep 30 10:29:26 <pompomJuice> no errors given
Sep 30 10:29:37 <pompomJuice> I am scared to fix things now
Sep 30 10:29:39 <bluelightning> er
Sep 30 10:29:48 <pompomJuice> all my patches contain custom workdirs
Sep 30 10:29:52 <bluelightning> I doubt you could have added a malformed patch without an error being given
Sep 30 10:29:59 <bluelightning> hold on a sec
Sep 30 10:30:13 <pompomJuice> that 1.0-r22
Sep 30 10:30:23 <bluelightning> being that we're applying effectively with -p1, the first directory of the path is ignored, it doesn't matter what it is
Sep 30 10:30:25 <pompomJuice> it has since changed to something that looks like 1.0.1-r45
Sep 30 10:30:32 <pompomJuice> aah
Sep 30 10:30:33 <pompomJuice> ok
Sep 30 10:30:35 <pompomJuice> that helps
Sep 30 10:30:38 <bluelightning> don't panic ;)
Sep 30 10:30:42 <pompomJuice> I'm panicing
Sep 30 10:30:51 <pompomJuice> wow ok
Sep 30 10:31:02 <pompomJuice> ok everything is cool then
Sep 30 10:31:11 <pompomJuice> since my older patches to work
Sep 30 10:31:20 <pompomJuice> ok i'm calm now
Sep 30 10:32:02 <pompomJuice> aah thanks man
Sep 30 10:32:08 <pompomJuice> I totally freaked out now
Sep 30 10:53:44 <woglinde> 3
Sep 30 11:42:33 <bencoh> is there any reason why we dont ship perl with Config_git.pl ?
Sep 30 11:43:36 <bencoh> (Config_heavy.pl shipped with perl complains about it, dunno why it should bother)
Sep 30 15:50:41 <woglinde> bluelightning ping
Sep 30 16:00:34 <bluelightning_> woglinde: pong
Sep 30 16:03:00 <woglinde> bl I would like to extend sdk_populate functions in an own layer where should I start
Sep 30 16:06:22 <bluelightning_> woglinde: what kind of extensions are you making?
Sep 30 16:08:19 <woglinde> bluelightning my customer sets TOOLCHAIN_OUTPUTNAME = "${SDK_NAME}-toolchain...-${DISTRO_VERSION}-${DATETIME}
Sep 30 16:08:34 <woglinde> and wants me to set symlinks to ${SDK_NAME}-toolchain...-${DISTRO_VERSION}
Sep 30 16:09:10 <woglinde> like images do
Sep 30 16:09:27 <woglinde> so I need some hook into deploy_sdk-toolchain_something
Sep 30 16:09:38 <woglinde> I do not want to copy the whole class
Sep 30 16:09:50 <woglinde> but if nothing helps I have to
Sep 30 16:09:53 <bluelightning> ok let me have a look at the code
Sep 30 16:10:39 <woglinde> thanks
Sep 30 16:11:32 <woglinde> but I fear there is nothing which would load my snippet/fragment from the bsp layer
Sep 30 16:14:12 <woglinde> hm ah okay
Sep 30 16:14:26 <woglinde> there are some toolchain recipes in the bsp
Sep 30 16:14:31 <woglinde> so I can hook into them
Sep 30 16:22:49 <bluelightning> woglinde: for the python side of things I don't think there is such a mechanism no
Sep 30 16:23:08 <bluelightning> but for something like this you might be able to do it via a postprocessing function
Sep 30 16:26:03 <woglinde> bluelightning I think I will add an extra task make it similiar to the sdk_deploy_base_class
Sep 30 16:26:12 <woglinde> looks promising so far
Sep 30 16:26:43 <bluelightning> it seems you could do do_populate_sdk_append() - that's a python function
Sep 30 16:27:46 <woglinde> hm
Sep 30 16:27:50 <woglinde> yes
Sep 30 16:34:08 * kergoth runs across https://autotools.io/
Sep 30 16:35:01 * darknighte gets curious and opens kergoth's link
Sep 30 16:38:12 <woglinde> kergoth hm good site
Sep 30 16:38:27 <kergoth> seems like a nice alternative to digging through the official manuals
Sep 30 16:38:31 <koen> kergoth: that doc came in handy when OE-core killed off binconfig scripts
Sep 30 16:38:32 <woglinde> very helpful for autotools beginners
Sep 30 16:38:47 <kergoth> ah, nice
Sep 30 17:03:14 <woglinde> good works as expected
Sep 30 17:34:49 <Crofton> khem, what prompted the libdivecomputer update?
Sep 30 17:35:04 <Crofton> I really need to try running subsurface on an embedded board :)
Sep 30 17:48:07 <koen> prolly glibc problems
Sep 30 17:48:25 <koen> Crofton: didn't I show subsurface at ELC in 2012?
Sep 30 17:48:54 <kergoth> tar: license-destdir/xz/generic_GPLv2: file changed as we read it in sstate_create_package. anyone else running into these? they keep breaking our jenkins builds
Sep 30 17:55:12 <Crofton> koen, I think so
Sep 30 17:55:25 <Crofton> I have much more interesting data for it now
Sep 30 18:39:36 <Crofton> I'm seeing some host contamination using an sdk
Sep 30 18:39:37 <Crofton> http://pastebin.com/ZGZ1PGm7
Sep 30 18:39:42 <Crofton> this ring a bell with anyone
Sep 30 18:41:39 <Crofton> I've been pointed at this: https://github.com/archlinuxarm/PKGBUILDs/issues/255
Sep 30 18:44:25 <khem> Crofton: Fetch issues 
Sep 30 18:44:39 <Crofton> ah
Sep 30 18:44:40 <Crofton> ok
Sep 30 18:44:50 <Crofton> can you read the arch linux bug
Sep 30 18:45:01 <Crofton> it looks like it is in our sdks
Sep 30 18:45:15 <Crofton> just sont wondering if you had taken up diving
Sep 30 18:50:20 <chouimat|busy> hi
Sep 30 18:51:11 <khem> Crofton: No heh, I am happy in swimming pools
Sep 30 18:53:46 <Crofton> I had to link stubs-hard.h to stubs-soft.h (or vice versa)
Sep 30 18:57:28 <khem> Crofton: thats wrong
Sep 30 18:57:39 <khem> it means your build is defaulting to soft-float 
Sep 30 18:57:53 <khem> there might be bigger issues down the road even if it builds 
Sep 30 18:58:10 <khem> so make sure that CC has TOOLCHAIN_OPTIONS passed to component build systemd
Sep 30 18:58:12 <khem> systemd
Sep 30 18:58:16 <Crofton> urg good point
Sep 30 18:58:18 <khem> heh
Sep 30 18:58:30 <Crofton> I think the gnuradiop cmake is clubbing the CC var
**** ENDING LOGGING AT Wed Oct 01 03:00:00 2014