**** BEGIN LOGGING AT Tue Jun 09 02:59:58 2015
Jun 09 04:32:15 <frackers> Can someone help a noob with getting an ARM image that runs OK on the target to run under qemu?
Jun 09 04:39:31 <redengin> frackers, I can try my best to help you, what errors are you seeing?
Jun 09 04:40:45 <frackers> The zimage kernel I'm using doesn't see the init in the ext3 filesystem image
Jun 09 04:41:04 <frackers> Gets usual kernel panic
Jun 09 04:41:53 <redengin> are you using the yocto qemu launch scripts?
Jun 09 04:44:12 <frackers> yup - I've built the latest sample using poky zip from git and that runs fine. The image created following the instructions at variscite for their var_som_mx6 runs OK from sdcard but using 'runqemu' fails. The ext3 image looks OK but since it usually starts from uboot I wonder if I'm missing something
Jun 09 04:46:55 <frackers> Supper time - back later...
Jun 09 08:03:38 <RagBal> abelloni, I'm running into the same issue as you mentioned 2014-10-08 in here: error: Can't install libgles-omap3-es5-5.01.01.02-r38.1@cortexa8hf_vfp_neon: no package provides ld-linux.so.3(GLIBC_2.4)
Jun 09 08:04:10 <RagBal> abelloni, this is in reference to yesterday when you gave me the advise to build libgles-omap3 without distro
Jun 09 08:09:24 <bluelightning> morning all
Jun 09 08:13:12 <redengin> morning
Jun 09 08:40:33 <ryoshu> good morning
Jun 09 08:44:34 <sm0ketst> hi all, how can I invoke 'nasm' from a recipe (is DEPENDS="nasm-native" only required)? I only need to do: 'nasm -f bin asm.file -o execfile'
Jun 09 08:45:19 <redengin> sm0ketst, should work, have you tried it?
Jun 09 08:47:11 <sm0ketst> redengin: not yet, just figuring out if i should use something like ${AS} -f bin ... but for nasm
Jun 09 09:01:35 <bboozzoo> hi all, has anyone used swupdate, specifically this thing http://sbabic.github.io/swupdate/ ? I recall bluelightning mentioned it on the mailing list, but haven't really seen it being mentioned in other discussions
Jun 09 09:02:33 <LetoThe2nd> bboozzoo: can't share too many details, but we're using it and it works(TM)
Jun 09 09:15:58 <sm0ketst> redengin: worked by just calling 'nasm' from the do_compile, thanks! i had to add two inhibit to avoid QA complaining about the debug packages but i think it is ok, it is only a simple load/stress bin to run
Jun 09 09:34:27 <LetoThe2nd> is there some additional magic that i need to include a kernel header from include/uapi/linux/xyz.h into the images' /usr/include? the module gets properly built and installed, but the file is just not there.
Jun 09 09:37:17 <LetoThe2nd> (if i manually do make header_install, the header is there, by the way)
Jun 09 09:43:40 <_4urele_> Hi I just took the latest version on master, and I get this error : https://gist.github.com/4urele/6a9c82b99dd0cce3ad50
Jun 09 09:43:43 <LetoThe2nd> so is kernel.bbclass some additional mechanism? or a kind of filtering?
Jun 09 09:43:50 <likewise> LetoThe2nd: look in your deploy/rpm/ and see if there is a -dev package for your module
Jun 09 09:44:08 <_4urele_> it seems that a patch doesn't work anymore...
Jun 09 09:45:08 <LetoThe2nd> likewise: nope, the modules don't seem to get dev pacakges
Jun 09 09:46:31 <likewise> LetoThe2nd: I am probably mistaken. I thought a -dev package was created for the headers. Hmmm. Let me see.
Jun 09 09:48:42 <LetoThe2nd> likewise: kernel-dev gets created, but that also doesn't include the header. it just has a complete copy under /usr/src/kernel, which is not really the same
Jun 09 09:50:50 <bluelightning> LetoThe2nd: perhaps use find under packages-split in the workdir for the kernel to see which package it went into?
Jun 09 09:51:52 <LetoThe2nd> bluelightning: hm. none.
Jun 09 09:51:58 <likewise> bluelightning: That's what I thought, but it seems we do not build UAPI dev packages for module automatically (or I cannot find it).
Jun 09 09:52:05 <likewise> similar reports: https://lists.yoctoproject.org/pipermail/meta-freescale/2015-January/012144.html
Jun 09 09:52:16 <likewise> https://lists.yoctoproject.org/pipermail/meta-freescale/2015-January/012156.html
Jun 09 09:52:57 <bluelightning> hmm, it's not really something I'm familiar with myself unfortunately...
Jun 09 09:53:17 <LetoThe2nd> i wouldn't care that much for the package that goes into the target, but as it doesn't get added into the sdk too, its a bit of a showstopper when you want to develop against it.
Jun 09 09:53:58 <likewise> LetoThe2nd: I would expect it to end up in the 1) sysroot, 2) SDK, and 3) as a -dev package for the target.
Jun 09 09:54:16 <LetoThe2nd> likewise: some expectations here. but none applies.
Jun 09 09:55:02 <LetoThe2nd> the kernels make headers_install seems to do the right thing(TM)
Jun 09 09:55:07 <likewise> LetoThe2nd: well good point you bring it up.
Jun 09 09:55:08 <likewise> https://lists.yoctoproject.org/pipermail/yocto/2015-March/024155.html
Jun 09 09:55:49 <likewise> https://lists.yoctoproject.org/pipermail/yocto/2015-March/024156.html
Jun 09 09:57:14 <likewise> https://lists.yoctoproject.org/pipermail/linux-yocto/2014-April/002178.html
Jun 09 09:58:07 <likewise> The last two threads give some ideas.
Jun 09 09:58:33 <likewise> They are the neatest work-arounds I would say.  Now that I read them, I remember to have run into this before.
Jun 09 09:59:20 <LetoThe2nd> likewise: yeah, probably the least-impact solution is to just add the file into the project i'm developing for now. but i'd say that "pretty" is something different.
Jun 09 09:59:23 <likewise> There was discussion on whether we should include the UAPI headers in linux-libc-headers, but this is not recommended as they are sanitized (for whatever that means).
Jun 09 10:00:09 <likewise> LetoThe2nd: I would surely expect we had kernel-module-xyz-dev packages...
Jun 09 10:00:55 <LetoThe2nd> *sigh
Jun 09 10:02:27 <LetoThe2nd> likewise: i don't think that its possible that way, because in KBuild there is no relation between a specific header and a module
Jun 09 10:04:43 <likewise> LetoThe2nd: Hmm, indeed. Only building out-of-tree modules with their own meta data could steer the package creation.
Jun 09 10:05:09 <likewise> LetoThe2nd: But if you add to the kernel itself, you can also bbappend the metadata for your specific kernel
Jun 09 10:05:36 <LetoThe2nd> and as i understood it, the addition of new header into uapi is the recommended way, so we'll certainly need a fix someday
Jun 09 10:13:19 <bluelightning> I will say if there's functionality missing it would be worth filing an enhancement bug if there isn't already one to track this
Jun 09 11:34:04 <niteshnarayanlal> hi if I want to copy a complete director in the rootfs
Jun 09 11:34:10 <niteshnarayanlal> then only install -m won't do
Jun 09 11:34:18 <niteshnarayanlal> any help
Jun 09 11:42:57 <RagBal> error: Can't install libgles-omap3-es3-5.01.01.02-r38.1@cortexa8hf_vfp_neon: no package provides libews.so
Jun 09 11:43:02 * RagBal getting frustrated
Jun 09 12:25:48 <_4urele_> hi again,
Jun 09 12:26:23 <bluelightning> niteshnarayanlal: you can alternatively do cp -r if you need to
Jun 09 12:27:26 <_4urele_> I'm on poky master branch I'm using glibc with a custom distro
Jun 09 12:27:43 <_4urele_> I have a patch which doesn't apply correctly
Jun 09 12:28:26 <_4urele_> as far as I checked this seems to be normal : as far as I can see the targeted file is too different to apply this patch
Jun 09 12:29:34 <_4urele_> on my poky tree I can see that I'm using glibc 2.21 and the patch which doesn't apply is ./meta/recipes-core/glibc/glibc/grok_gold.patch
Jun 09 12:29:47 <_4urele_> if anyone has any idea...
Jun 09 12:29:49 <bluelightning> _4urele_: we do run regular builds, is there something in your custom distro that might be influencing this?
Jun 09 12:31:04 <_4urele_> I don't think so, as far as I can see the patch is applied with any configuration
Jun 09 12:31:54 <bluelightning> that patch did get updated when we upgraded to 2.21
Jun 09 12:32:01 <bluelightning> (going by the git history)
Jun 09 12:32:51 <bluelightning> long shot but you didn't by any chance change PATCHTOOL ?
Jun 09 12:34:47 <_4urele_> bluelightning, no, and the patch and configure.ac (because this is where it fails) are really different, I tried to checkout again and so on
Jun 09 12:35:48 <abelloni> _4urele_: I thought you were using buildroot ;) (running joke)
Jun 09 12:37:45 <_4urele_> abelloni, long run!
Jun 09 12:44:14 <bluelightning> well, FWIW, glibc do_patch just succeeded here
Jun 09 12:44:43 <bluelightning> that was in a from-scratch build though
Jun 09 12:45:02 <bluelightning> _4urele_: did you try bitbake -c clean glibc ?
Jun 09 12:45:16 <_4urele_> bluelightning, thanks, it seems that the cloned version is not the good one in my work directory... it is the glibc 2.20
Jun 09 12:45:34 <_4urele_> bluelightning, I will try cleanall again...
Jun 09 12:45:40 <bluelightning> er, how did that happen?
Jun 09 12:47:16 <_4urele_> bluelightning, I'm sharing the download directory with another yocto version
Jun 09 12:47:32 <_4urele_> bluelightning, maybe this is not a good idea
Jun 09 12:47:57 <bluelightning> ideally that shouldn't matter, though having those actually running builds at the same time probably isn't a good idea if you're doing that
Jun 09 12:48:08 <bluelightning> merely sharing the same dir should be just fine though
Jun 09 12:48:27 <bluelightning> I switch back and forth between branches with the same DL_DIR
Jun 09 12:49:55 <_4urele_> I will check but I just updated from an old 1.7 to the new master, when I "run bitbake-layers show-recipes glibc"
Jun 09 12:50:42 <_4urele_> it says 2.21, and obviously it uses a 2.20 (which is probably coming from 1.7...) (I'm using tarballs also...)
Jun 09 12:52:15 <RagBal> abelloni, I'm still unable to build libgles-omap3, I tested with oe-core like you told me
Jun 09 12:52:42 <RagBal> abelloni, I'm running into the same issue as you mentioned 2014-10-08 in this channel: error: Can't install libgles-omap3-es5-5.01.01.02-r38.1@cortexa8hf_vfp_neon: no package provides ld-linux.so.3(GLIBC_2.4)
Jun 09 12:52:49 <_4urele_> maybe I did something wrong... I erased everything then I will retry, many thanks for the help
Jun 09 12:54:38 <abelloni> RagBal: yes, this seems familiar to me, I managed to solve this, unfortunately, I don't exactly remember how
Jun 09 12:56:26 <RagBal> abelloni, aww bummer =(
Jun 09 12:58:07 <RagBal> abelloni, when using poky I run into libgles-omap3 unable to install because no package provides libews.so, so I guess it's not meant for me to use libgles
Jun 09 13:15:37 <bluelightning> _4urele_: I'm still a little bit confused about your configuration - are you overlaying or bbappending the glibc recipe at all?
Jun 09 13:20:24 <_4urele_> bluelightning, you're right I'm using another layer, I checked removing the layer seems to be ok
Jun 09 13:20:54 <bluelightning> _4urele_: was it a public layer causing the issue or something you'd set up yourself?
Jun 09 13:21:06 <_4urele_> bluelightning, I just found a bbclass which is fixing the SRCREV for glibc...
Jun 09 13:21:22 <bluelightning> a bbclass?
Jun 09 13:21:23 <_4urele_> bluelightning, it is closed source...
Jun 09 13:21:56 <bluelightning> it's pretty unorthodox to be setting that from a bbclass
Jun 09 13:22:01 <_4urele_> bluelightning, yes with multiple versions set
Jun 09 13:23:20 <_4urele_> bluelightning, anyhow I will discuss this with some people ;)
Jun 09 13:23:48 <bluelightning> _4urele_: ok, well at least you found the source of the issue :)
Jun 09 13:24:13 <_4urele_> bluelightning, many thanks
Jun 09 13:24:30 <bluelightning> I wonder if we should have some sort of check to see if the actual version fetched matches PV
Jun 09 13:25:12 <bluelightning> that might not be practical though
Jun 09 13:27:42 <_4urele_> bluelightning, maybe something which tells what impacts the recipes (local.conf, bbclass, bbappend, ...)
Jun 09 13:28:51 <bluelightning> that would be tricky to do generically, but worth thinking about yes
Jun 09 13:29:01 <_4urele_> it is hard to find what modify the recipe behaviour (as far as I know, maybe you have some magic to get those kind of information)
Jun 09 13:29:44 <bluelightning> bitbake -e recipename is probably the closest thing we have to that on an individual recipe basis, but then of course you need to know what you're looking for
Jun 09 14:16:53 <abelloni> RagBal: I did that: http://hastebin.com/ojucicitiv.md
Jun 09 15:41:53 <paulg> patching a bb that still has a PR= in it ; should I also delete that line while there?
Jun 09 15:42:53 <bluelightning> paulg: if you are increasing the PV value as part of the change, yes
Jun 09 15:43:15 <bluelightning> if not, it should stay
Jun 09 15:44:34 * paulg had no intention of touching PR or PV originally....
Jun 09 15:46:54 <bluelightning> (renaming the recipe to change the version number counts as changing PV, but you probably know that ...)
Jun 09 15:49:42 <paulg> you'd be surprised how little I know when it comes to recipe magic.  :)
Jun 09 15:50:58 <bluelightning> ok, FYI then ;)
Jun 09 18:22:09 <dasabhi> hello any one there?
Jun 09 18:22:48 <dasabhi> i have a few questions to ask about the galileo board i am currently working with
Jun 09 18:23:16 <dasabhi> trying to update the linux kernel on the board
Jun 09 18:23:30 <bluelightning> dasabhi: if you ask your question we will try to answer
Jun 09 18:23:39 <dasabhi> okay perfect!
Jun 09 18:23:58 <bluelightning> (FWIW I did say the same thing yesterday but you vanished shortly after...)
Jun 09 18:24:00 <dasabhi> so i have a gentoo image on the board which is booting as expected
Jun 09 18:24:21 <dasabhi> but i can't connect to the internet with it
Jun 09 18:24:29 <dasabhi> and yeah sorry about that i had to leave LOL
Jun 09 18:24:36 <dasabhi> should have said something!
Jun 09 18:25:15 <dasabhi> so my friends at work tell me that i should update the kernel with modules and that it will allow internet access
Jun 09 18:25:54 <dasabhi> but the documentation for the board isn't working out that well for me
Jun 09 18:26:45 <bluelightning> ok, so... if this is a question about using the board itself, I think the Intel Makers forum is going to be your best bet rather than here
Jun 09 18:27:10 <bluelightning> this channel is for discussion about the Yocto Project
Jun 09 18:27:20 <dasabhi> yeah you are right but that is also why i am here
Jun 09 18:27:40 <tripzero> anyone seen "shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
Jun 09 18:27:45 <dasabhi> see the documentation i was reading said that it used yocto to build their default images
Jun 09 18:27:46 <tripzero> when building?
Jun 09 18:28:04 <bluelightning> tripzero: can't say that I have...
Jun 09 18:28:44 <tripzero> i'm trying to create a bbappend that appends onto SRC_URI
Jun 09 18:28:45 <dasabhi> wooow sergeiK is in this chat room!
Jun 09 18:28:51 <tripzero> i get that error during the unpack step
Jun 09 18:29:07 <dasabhi> i was reading this docs and several questions came up
Jun 09 18:29:31 <dasabhi> is sergei active during a particular time of day?
Jun 09 18:29:57 <bluelightning> I can't say, I'm not sure I've noticed him saying anything here though I'm not always active myself
Jun 09 18:29:59 <tripzero> bluelightning: are using meta-intel?
Jun 09 18:30:17 <dasabhi> alright then i will ask this, do you guys know how bitbake works?
Jun 09 18:30:21 <bluelightning> tripzero: I do on occasion when I'm building for a board it supports, yes
Jun 09 18:30:22 <tripzero> err, dasabhi are using meta-intel?
Jun 09 18:30:34 <tripzero> sorry, bluelightning wrong person to ask ;)
Jun 09 18:30:35 <bluelightning> dasabhi: pretty well yes
Jun 09 18:30:37 <dasabhi> i was reading this documentation and it said to use the bitbake command, but bitbake isnt a bash command...
Jun 09 18:31:09 <tripzero> dasabhi: you need to source oe-init-build-env first
Jun 09 18:31:11 <bluelightning> dasabhi: if you want to use bitbake you need to follow the proper set of setup instructions
Jun 09 18:31:11 <dasabhi> his documentation told me to unzip a BSP and then use bitbake to build something
Jun 09 18:31:30 <dasabhi> yeah his docs didn't really mention that
Jun 09 18:31:31 <tripzero> his docs may be missing a step
Jun 09 18:32:02 <dasabhi> so do i just type source oe-init-build-env ?
Jun 09 18:32:23 <bluelightning> there's more to it than that, you have to actually be in the directory containing that file
Jun 09 18:32:27 <dasabhi> and then use the bitbake command?
Jun 09 18:32:31 <bluelightning> I'm not sure what BSP you have unzipped
Jun 09 18:33:01 <dasabhi> http://www.malinov.com/Home/sergey-s-blog/intelgalileo-buildinglinuximage this is the link i was using
Jun 09 18:33:08 <dasabhi> it was the BSP for the galileo board
Jun 09 18:33:39 <bluelightning> that set of instructions and the BSP it points to is positively ancient by now
Jun 09 18:33:47 <dasabhi> yeah i have no idea how to setup this bitbake thing, so i guess its a good place to start
Jun 09 18:34:09 <dasabhi> no i found the BSP
Jun 09 18:34:42 <dasabhi> but yeah some of the files inside like meta clanton had newer versions
Jun 09 18:35:19 <bluelightning> this is really something for the maker forums, if you search for bitbake there you'll find it has been discussed a number of times
Jun 09 18:35:29 <bluelightning> I have to go catch a train, bbl
Jun 09 18:35:46 <dasabhi> maker forums on the galileo site? :S
Jun 09 21:28:13 <realBigfoot> I am installing about a thousands files in a image and I'm putting like this -> FILES_${PN} += "/PATH_TO_FOLDER". When running the installation i got an error that i have to set the name of the files. Is there a way to skip this ?
Jun 09 21:41:25 <bluelightning> realBigfoot: what's the exact message you are receiving?
Jun 09 21:55:28 <realBigfoot> ERROR: RECIPE_NAME not found in the base feeds
Jun 09 21:55:34 <realBigfoot> bluelightning, ^
Jun 09 21:57:57 <bluelightning> realBigfoot: are you also receiving an "installed but not shipped" warning?
Jun 09 21:58:18 <realBigfoot> bluelightning, yes... with the files i asked to be copied
Jun 09 21:58:39 <bluelightning> realBigfoot: ok, so whatever path you are adding to FILES_${PN} is incorrect
Jun 09 21:58:53 <realBigfoot> bluelightning, sorry i didn't show this message i was searching it but i couldn't find it anymore (dunno why)
Jun 09 21:59:16 <bluelightning> realBigfoot: note that FILES expects the path as it would appear in the final image, not a path on the build host
Jun 09 21:59:29 <realBigfoot> bluelightning, that makes sense
Jun 09 22:03:05 <realBigfoot> bluelightning, thanks :) it worked!
Jun 09 22:03:55 <bluelightning> np :)
Jun 09 22:08:16 <xulfer> Hm given a choice of making a legacy gcc work on a newer yocto version vs downgrading a large setup all the way to dora... which would probably be easier?
Jun 09 22:10:51 <bluelightning> that's a tough call
Jun 09 22:11:35 <xulfer> Yeah.  I have a full BSP and everything running on daisy, and apparently it uses some daisy specific features.
Jun 09 22:11:44 <xulfer> Not to mention all the other bbappend files I have going on in other layers. :/
Jun 09 22:12:10 <bluelightning> my gut says you may be better off with the legacy gcc on a newer version, at least then you aren't heading further away from something current at least
Jun 09 22:12:14 * paulg_ wonders what is depending on the old toolchain
Jun 09 22:12:24 <xulfer> My boards kernel
Jun 09 22:12:36 <xulfer> It doesn't compile properly on GCC 4.8.  Requires GCC 4.7
Jun 09 22:13:10 <bluelightning> if this is for ARM I think we dealt with this issue before a number of times
Jun 09 22:13:19 <paulg_> if it were me, I'd just fix the kernel, but then again, that is where I spend most of my day.
Jun 09 22:13:20 <xulfer> Well it compiles properly, but rather doesn't run properly.  I thought it was an issue on my side, but I was able to track down a TI confirmation today.
Jun 09 22:13:21 <bluelightning> requires a patch or two for the kernel
Jun 09 22:13:33 <bluelightning> hang on boot?
Jun 09 22:13:42 <xulfer> Yes
Jun 09 22:14:02 <xulfer> No u-boot output.  (running an OMAP 4460 if that helps)
Jun 09 22:14:10 <paulg_> back in the day it was always -Os  that seemed to screw ARM.
Jun 09 22:14:18 <xulfer> The TI stuff I read MENTIONED patches for it, but didn't provide any information.
Jun 09 22:14:31 <bluelightning> let me see if I can track down the most recent post about that
Jun 09 22:15:04 <paulg_> wait, the u-boot binary is busted, or you really mean that you don't see any early serial console output from the kernel?
Jun 09 22:15:46 * paulg_ assumes folks aren't changing u-boot binaries on a regular basis....
Jun 09 22:16:01 <bluelightning> I've no idea if this will help but this was what I was referring to: http://lists.openembedded.org/pipermail/openembedded-core/2015-April/104352.html
Jun 09 22:16:11 <xulfer> No serial, but it's not u-boot.  I have a working version on the same u-boot
Jun 09 22:17:28 <xulfer> and with TI confirming it as a known issue on this specific board I imagine GCC is the issue.
Jun 09 22:19:07 <paulg_> I'd try the two patches from bluelightning, and if you still have no luck, you can...
Jun 09 22:20:36 <paulg_> ...pseudo bisect by sticking object files from the working kernel build into the failed one and relinking it (starting in dirs that are related to early setup).
Jun 09 22:21:09 <paulg_> once you get it down to a single object, you can disassemble and compare and figure out wtf.
Jun 09 22:21:26 <paulg_> it isn't pretty but I've done it before with success to track down a tc bug.
Jun 09 22:25:41 <xulfer> bluelightning:  Did some more in-depth googling based on your post, and those are indeed the patches.
Jun 09 22:27:39 <paulg_> yeah,  hope it works for you, since that smells a lot easier than digging in and solving wtf from scratch.
Jun 09 22:32:04 <xulfer> Yeah
Jun 09 22:32:05 <xulfer> http://thread.gmane.org/gmane.linux.embedded.yocto.meta-ti/2915/focus=2921
Jun 09 22:32:11 <xulfer> That's referring to my specific board even.
Jun 09 22:39:06 <paulg_> I'd be tempted to move the whole thing to a newer kernel too, assuming it didn't have a dumptruck worth of invasive bsp specific/vendor specific patches.
Jun 09 22:39:59 <xulfer> it does
Jun 09 22:40:05 <paulg_> figures....
Jun 09 22:51:30 <xulfer> Blah.  Those patches are pretty different than what I've got here in 3.4 though. :(
Jun 09 22:52:00 <xulfer> Wonder if there'd be a lot of harm in just patching in the whole memset.S file from say 3.10
Jun 09 22:53:12 <paulg_> xulfer, yeah you can probably adapt in a chunk like that w/o too many API changes.
Jun 09 22:53:32 <paulg_> adapt the object file bisect technique to source file based.
Jun 09 22:54:30 <paulg_> maybe, depending on your end goal, you won't care to mine in deeper than file level, once you find the file that gets munged.
Jun 09 23:01:57 <frackers> Morning all!
Jun 09 23:02:16 <frackers> Should I expect a filesystem built to imx6 to run under qemu arm?
Jun 09 23:30:09 <frackers>  /msg NickServ VERIFY REGISTER frackers dhcykrcyytdj
Jun 09 23:35:20 <frackers> So how do I build an arm project so it runs under qemu - its fince on the target (imx6)
Jun 10 00:56:19 <xulfer> Thanks for the help guys.  Finished back porting the patch and it worked
Jun 10 01:54:29 <paulg_> xulfer, nice; glad you avoided the suck factor of wading through tracking down a toolchain related issue.
Jun 10 01:55:38 <xulfer> Yeah it would have taken days
Jun 10 01:56:23 <paulg_> might have, depending on experience, but yeah best avoided if possible...
Jun 10 02:03:07 <xulfer> Well my experience is pretty minimal
Jun 10 02:03:33 <xulfer> Came to this from years of buildroot maybe 4 months ago?
Jun 10 02:03:52 <xulfer> Steep learning curve but this channel has helped me immensely
**** ENDING LOGGING AT Wed Jun 10 02:59:59 2015