**** BEGIN LOGGING AT Wed Apr 29 02:59:59 2015
Apr 29 06:50:02 <redengin> good evening
Apr 29 08:23:41 <bluelightning> morning all
Apr 29 08:25:03 <redengin> morning
Apr 29 08:34:06 <lpapp> good morning
Apr 29 09:48:23 <lpapp> bluelightning: is it possible to easily tell Yocto that I want to build some specific software from recipe by a different toolchain than what Yocto is using?
Apr 29 09:48:53 <lpapp> i.e. if some software does not build with the new toolchain that Yocto ships, people could still update, but for that particular software, they would use the good old toolchain that just works.
Apr 29 09:49:15 <redengin> lpapp, which toolchain gcc?
Apr 29 09:49:21 <bluelightning> lpapp: there is http://openembedded.org/wiki/Adding_a_secondary_toolchain
Apr 29 09:49:38 <bluelightning> lpapp: absolutely no guarantees you will get it to work, but it's there
Apr 29 09:49:47 <lpapp> interesting
Apr 29 09:51:01 <lpapp> thanks, I will have a look.
Apr 29 09:51:45 <lpapp> "In addition related components such as gdb, cross-prelink, mklibs and others provider additional toolchain functionality." -> hmm, that is probably a typo.
Apr 29 09:52:22 <redengin> lpapp, which toolchain are you using?
Apr 29 09:52:48 <redengin> I especially want to know if its microsoft based
Apr 29 09:54:23 <redengin> I submitted some code, but it failed under a microsoft compiler....   I think its my use of class initializers without a constructor
Apr 29 10:02:31 <lpapp> redengin: I want to build the linux kernel with dylan's toolchain inside daisy.
Apr 29 10:03:00 <redengin> ah, I see
Apr 29 10:03:21 <redengin> did the link give you enough info?
Apr 29 10:05:46 <lpapp> I will read it soon in details.
Apr 29 10:05:57 <lpapp> but it makes me feel uncomfortable to use since it is not in the official reference manual.
Apr 29 10:18:16 <bluelightning> well, we hope not to be in situations where this kind of thing is necessary
Apr 29 10:19:10 <redengin> what is gained by the dylan toolchain?
Apr 29 10:19:22 <bluelightning> lpapp is doing this solely to work around what appears to be a bug, root-causing and fixing that bug is what ought to be done
Apr 29 10:20:40 <redengin> are we talking about the gcc linus anger?
Apr 29 10:20:49 <lpapp> no
Apr 29 10:20:53 <lpapp> this predates that
Apr 29 10:20:56 <lpapp> (I think)
Apr 29 10:21:09 <lpapp> and yes, bluelightning is correct that it is a workaround
Apr 29 10:21:17 <lpapp> do not have the expertise for the real solution, unfortunately.
Apr 29 10:21:25 <lpapp> nor the funding to hire contractors at this point.
Apr 29 10:22:08 <bluelightning> there is one other thing you could try - you could appeal for help on the mailing list
Apr 29 10:22:28 <bluelightning> in case someone else has dealt with the same situation
Apr 29 10:22:36 <lpapp> sure, I was going to do that, but of course without any expectation.
Apr 29 10:23:00 <lpapp> it is possible that someone replies in an hour, but it is also possible that I never hear anything back from the TI guys.
Apr 29 10:23:09 <bluelightning> you'd have to describe the problem from scratch in detail - exact kernel version, gcc version, target platform, what you tried in order to work around the issue, etc.
Apr 29 10:23:15 <lpapp> in either case, I need to proceed with my project.
Apr 29 10:23:35 <lpapp> so if something turns up, we will switch the strategy.
Apr 29 10:23:42 <lpapp> but we cannot rely on that at this point.
Apr 29 10:23:55 <lpapp> yes, I agree.
Apr 29 10:23:58 <lpapp> that is why I did not do it yet.
Apr 29 10:24:07 <lpapp> it is 1-2 hours of work to properly write everything down.
Apr 29 10:24:16 <lpapp> and then of course there is the chance that many people will skip it as tl;dr
Apr 29 10:24:18 <bluelightning> sure, but there's a chance you will get a fix that is simpler than the workaround
Apr 29 10:26:35 <lpapp> I thought this separate layer would be simple to implement?
Apr 29 10:27:10 <redengin> lpapp, send a link to your layer so that I can see what you fixed
Apr 29 10:28:02 <lpapp> redengin: our layer is not open source I am afraid.
Apr 29 10:28:09 <lpapp> but I do not have any fix either to be honest.
Apr 29 10:28:17 <lpapp> I am just creating this new toolchain layer as I have to.
Apr 29 10:40:08 <lpapp> bluelightning: at least I asked around in #gcc and #kernelnewbies. That was a good start.
Apr 29 10:41:03 <JEEBsv> hmm, what's the correct way to make wic to use the label (or PARTUUID) as the root fs parameter
Apr 29 10:44:29 <bluelightning> JEEBsv: I don't have an answer to your question but FWIW I did enter a bug to cover your earlier feature request: https://bugzilla.yoctoproject.org/show_bug.cgi?id=7672
Apr 29 10:44:30 <yocti> Bug 7672: enhancement, Undecided, ---, eduard.bartosh, NEW , Allow automating running wic from the build system
Apr 29 10:44:45 <JEEBsv> thanks
Apr 29 10:46:00 <JEEBsv> will have to dig deeper into scripts then
Apr 29 10:54:28 <JEEBsv> seems like root_part_uuid is available in the EFI config creating script, but not used
Apr 29 10:55:23 <JEEBsv> pcbios script seems to be doing the same
Apr 29 11:33:39 <lpapp> I wonder how many people use this secondary toolchain option?
Apr 29 11:48:48 <JEEBsv> is there documentation on the wks file format available?
Apr 29 12:01:05 <bluelightning> JEEBsv: it's borrowed from Red Hat kickstart, so any documentation that exists for that ought to apply
Apr 29 12:04:27 <JEEBsv> okies...
Apr 29 12:11:58 <lpapp> bluelightning: what is the difference between Per recipe selection of toolchain usage
Apr 29 12:12:04 <lpapp> and Blacklist/Whitelist
Apr 29 12:12:34 <bluelightning> lpapp: I really don't know anything about the contents of that page, I've never used it
Apr 29 12:12:39 <otavio> Fido is failing in a weird way
Apr 29 12:12:41 <otavio> http://ci.ossystems.com.br/job/fsl-community-bsp-fido/23/console
Apr 29 12:12:54 <otavio> do someone has any idea what might be causing it?
Apr 29 12:13:44 <lpapp> hmm, who knows?
Apr 29 12:14:10 <lpapp> the quit redengin?
Apr 29 12:14:41 <lpapp> who is mhatle?
Apr 29 12:15:49 <bluelightning> lpapp: mhatle is Mark Hatle (fray)
Apr 29 12:17:33 <lpapp> fray: oh hello :)
Apr 29 12:18:03 <lpapp> bluelightning: thanks
Apr 29 13:06:07 <lpapp> fray: can you give me some guidance with this, e.g. a working example?
Apr 29 13:32:57 <ciprian-barbu> hello all, quick question, is it possible to write a bbappend that specifies a different place from where to download a package?
Apr 29 13:33:10 <JaMa> yes
Apr 29 13:33:35 <ciprian-barbu> something like modifying SRC_URI but not override it entirely?
Apr 29 13:33:39 <kergoth> a bbappend basically concatenates to the recipe. anything done in the recipe can be done in a bbappend, the only exception being _remove, which can't be undone
Apr 29 13:34:24 <ciprian-barbu> kergoth: I need to modify this recipe: https://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/tree/recipes-networking/openvswitch/openvswitch_2.1.3.bb
Apr 29 13:35:13 <ciprian-barbu> kergoth: but instead of http://openvswitch.org/releases/openvswitch-${PV}.tar.gz  I need my own version of openvswitch, but at the same time keeping everything else in SRC_URI
Apr 29 13:36:49 <kergoth> you'd want to use either anonymous or inline python to alter it, either using oe_filter_out() to remove the current one, and then add yours, or use .replace() on the string
Apr 29 13:44:15 <bluelightning> there is also externalsrc, if you are trying to point it at local in-development source
Apr 29 13:50:23 <lpapp> kergoth: are you familiar with this secondary toolchin?
Apr 29 13:52:22 <ciprian-barbu> thank you, I will try these suggestions
Apr 29 14:01:20 <lpapp> bluelightning: I can hear you ...
Apr 29 14:01:44 <lpapp> bluelightning: this is so underdocumented as well old stuff that asking on the gcc and the linux kernel mailing lists might be more productive.
Apr 29 14:02:24 <bluelightning> lpapp: I was thinking of our mailing list as a start, but possibly those too yes
Apr 29 14:02:54 <lpapp> you do not have many gcc and kernel hackers?
Apr 29 14:03:00 <lpapp> and this issue can be produced without Yocto, too?
Apr 29 14:03:13 <lpapp> (remember that I reproduced it with the Linaro toolchain yesterday)
Apr 29 14:03:26 <lpapp> (without using Yocto to look that out as the root cause)
Apr 29 14:05:44 <bluelightning> ah sorry, I missed that bit
Apr 29 14:05:50 <bluelightning> that would definitely open it to a wider audience
Apr 29 14:06:59 <bluelightning> we may not have many people that hack on gcc itself, but there may well be others who had to deal with the issue if you did
Apr 29 14:08:47 <lpapp> fair enough
Apr 29 14:08:58 <lpapp> the yocto community  does not just mean Intel
Apr 29 14:09:02 <lpapp> and the creators
Apr 29 14:09:10 <lpapp> I guess there are also company people following the list
Apr 29 14:09:17 <lpapp> who could speak up
Apr 29 14:09:20 <lpapp> good idea :)
Apr 29 14:22:32 <kergoth> lpapp: nope, never messed with it, sorry
Apr 29 14:23:27 <lpapp> ok, np, thanks for getting back to me.
Apr 29 14:26:19 <lpapp> bluelightning: my concern about this secondary toolchain is the fact that I cannot see examples.
Apr 29 14:35:51 <bluelightning> lpapp: sure, understood
Apr 29 14:41:06 <JEEBsv> I guess I was overoptimistic regarding --ptable=gpt actually working
Apr 29 14:45:48 <kergoth> gah, systemd implicitly pulls in valgrind/valgrind.h if it exists, no configure argument to disable it, will need to fix that to get deterministic builds
Apr 29 15:27:58 <kergoth> hmm
Apr 29 15:28:13 <kergoth> doesn't link against it, though, so shouldn't cause a huge problem, so why did my build fail..
Apr 29 15:29:01 <kergoth> suppose its possible there was a race, valgrind being cleaned and rebuilt due to a task change causing the header to vanish momentarily, after the detection in configure but before the use in compile
Apr 29 15:32:13 <bluelightning> kergoth: right, that's a common presentation of a race in our system
Apr 29 16:28:42 <khem`> bluelightning: there ?
Apr 29 16:28:50 <khem`> bluelightning: I tries PACKAGE_DEBUG_SPLIT_STYLE = "debug-without-src" in local.conf
Apr 29 16:28:51 <bluelightning> khem`: yep
Apr 29 16:28:56 <khem`> seems to have no effect
Apr 29 16:29:27 <khem`> oh I am looking at sstate size reduction. should that happen as well ?
Apr 29 16:29:40 <khem`> or just the -dbg packages ?
Apr 29 16:29:57 <bluelightning> I'd expect some of the sstate packages to get smaller yes
Apr 29 16:30:07 <khem`> I am dealing with huge sstate artifacts for chromium
Apr 29 16:30:21 <khem`> chrome binrary is 1.6G before strip
Apr 29 16:30:27 <bluelightning> I can't tell you offhand why it wouldn't have worked
Apr 29 16:30:35 <khem`> and it gets into three sstate artifacts
Apr 29 16:30:52 <khem`> daisy is what I am at
Apr 29 16:31:00 <khem`> and it should have worked there too as I see
Apr 29 16:32:36 <kergoth> ugh, systemd change ripples through quite a lot of recipes
Apr 29 16:32:39 * kergoth waits on rebuilds
Apr 29 16:33:05 <otavio> It seems something is broken in sysroot for libtool
Apr 29 16:33:08 <otavio> http://ci.ossystems.com.br/job/fsl-community-bsp-fido/23/console
Apr 29 16:33:35 <otavio> This shows up in a clean tmp from sstate-cache build
Apr 29 16:42:13 <maelcum> JaMa: hello. i see that you have two patches about license files / checksums in qtwebchannel 5.4.1 in jansa/master. those changes unbreak qtwebchannel 5.4.1. i suggest merging them to master :)
Apr 29 16:46:06 <kergoth> huh, looks like github recognizes bitbake as a language / filetype now. never noticed that. nice
Apr 29 16:46:19 <kergoth> https://github.com/MentorEmbedded/meta-mentor/search?l=bitbake
Apr 29 16:47:25 <bluelightning> kergoth: so we're no longer BlitzBasic? awesome...
Apr 29 16:47:49 <kergoth> indeed
Apr 29 16:47:58 <kergoth> no syntax highlighting of course, but at least it's the right type
Apr 29 16:51:16 <JaMa> maelcum: I plan to merge it today (waiting for 5.4.2 git recipes to verify more patches)
Apr 29 16:51:30 <maelcum> JaMa: okay, thanks!
Apr 29 16:58:21 <otavio> I sent the log information to the mailing list
Apr 29 16:58:27 <otavio> but it is puzzling me
Apr 29 17:16:05 <JaMa> maelcum: merged
Apr 29 17:16:13 <JaMa> to master as well as fido
Apr 29 17:24:47 <lpapp> bluelightning: should I choose openembedded-core or something else for the mailing list about the inquiry?
Apr 29 17:25:27 <bluelightning> lpapp: yeah the OE-Core list should work
Apr 29 17:29:40 <manuel_> hi, we have a bunch of jenkins jobs building our yocto images depending on the git branch they are pushed to. I would like to create a file in the resulting image that contains that git branch name and revision.
Apr 29 17:30:09 <manuel_> what is the best way to access evironment variables from the overall build process inside recipes?
Apr 29 17:33:28 <kergoth> have you ever actually read a recipe?
Apr 29 17:35:25 <manuel_> yes, i guess?
Apr 29 17:36:06 <manuel_> ok i think BB_ENV_EXTRAWHITE is what i was looking for
Apr 29 17:40:12 <armpit> JaMa, ping
Apr 29 18:08:48 <T0mW> does this work: "do_install_append_append ()" ?
Apr 29 18:09:01 <bluelightning> T0mW: no, just do do_install_append()
Apr 29 18:09:06 <bluelightning> _appends stack up
Apr 29 18:09:08 <T0mW> bah
Apr 29 18:09:09 <T0mW> heh
Apr 29 18:09:31 <bluelightning> i.e. they don't overwrite eachother, if that's what you were trying to avoid
Apr 29 18:09:42 <T0mW> OH! got it.
Apr 29 18:09:53 <T0mW> then concatonate
Apr 29 18:09:57 <bluelightning> yep
Apr 29 18:09:58 <T0mW> they concatonate
Apr 29 18:10:02 <T0mW> tnx
Apr 29 18:12:45 <kergoth> think of _append/_prepend as being operators, like .= and =., not as names
Apr 29 18:12:49 <kergoth> even though they're part of the name :)
Apr 29 18:12:52 <kergoth> (sort of0
Apr 29 18:23:01 <T0mW> yeah, I just realized if you had an 'append_append_append' and deleted the 'append_append' that it would break the 'append_append_append', heh
Apr 29 18:23:57 <JaMa> armpit: pong
Apr 29 18:36:25 <armpit> JaMa, did you ever seem my patch for meta-oe "[PATCH 00/33 v2][master] meta-oe misc build fixes" or did I send it to the wrong list or something else?
Apr 29 18:42:12 <JaMa> armpit: I don't remember seeing it in ML or on patchwork
Apr 29 18:43:11 <JaMa> but it's here http://permalink.gmane.org/gmane.comp.handhelds.openembedded/68489
Apr 29 18:44:39 <JaMa> armpit:  ok it's in spam :/
Apr 29 18:44:40 <armpit> k, so should I resend after rebasing ?
Apr 29 18:45:47 <JaMa> yes please (at least to test if gmail learned from "not spam"
Apr 29 18:45:48 <armpit> so did having [master] in the subject do that?
Apr 29 18:46:13 <JaMa> Andrea was also reporting that many oe-devel e-mails ended in spam folder :/
Apr 29 18:46:31 <JaMa> unfortunately the same is probably happening with patchwork account
Apr 29 18:50:46 <abelloni> otavio: do you also have issues with repo ?
Apr 29 18:52:37 <JaMa> armpit: do I still need something from "[PATCH 00/20 V2][Dizzy-next]" It was also in spam :/
Apr 29 19:03:19 <JaMa> armpit: I've rebased your branch and merged it to master-next
Apr 29 19:06:32 <JaMa> armpit: when resending please send patches as well as cover letter so that we can review on e-mail ("opencv: build issue" looks wrong)
Apr 29 19:06:51 <JaMa> you don't need to inherit blacklist and you should set COMMERCIAL_LICENSE instead of PNBLACKLIST
Apr 29 19:07:58 <JaMa> LICENSE_FLAGS = "commercial"
Apr 29 19:12:31 <armpit> k
Apr 29 19:15:49 <JaMa> armpit: also the bash/perl/python RDEPENDS can be NAKed by people who care more about the image size than some random unused script which happens to be included in PN (in many cases the proper fix is to move the unused script to separate package and add the RDEPENDS only there)
Apr 29 19:24:43 <otavio> abelloni: no, why?
Apr 29 19:28:02 <zerus> Hi. I have a patch (generated by using git-format-patch) that I try to apply on the kernel. But for some reason this specific patch isn't applied, but the build itself is succesful and I can apply it manually without any warning/errors (using devshell). My other patches are applied correct, only differences I'm aware of is that this patch is 'cherry-picked' from the beginning and the others are made from scratch. Any ideas where to start tr
Apr 29 19:28:29 <abelloni> otavio: it screws up the path to my git repositories
Apr 29 19:29:49 <abelloni> like:
Apr 29 19:29:50 <abelloni> fatal: 'hub.com/Freescale/meta-fsl-arm-extra' does not appear to be a git repository
Apr 29 19:29:53 <abelloni> fatal: 'hub.com/meta-qt5/meta-qt5' does not appear to be a git repository
Apr 29 19:29:56 <abelloni> fatal: Could not read from remote repository.
Apr 29 19:30:32 <abelloni> I don't know why, it strips "git" from all paths
Apr 29 19:47:46 <DS___> I'm using a layer from someone else that has a machine and some recipes with compatible_machine associated with that machine. I'd like to change something in the machine_name.conf file from that layer, but I'd prefer not to change any files in that layer. Is it possible to make an append to a machine, or what is the best approach to do this?
Apr 29 19:52:44 <DS___> I just found out about MACHINEOVERRIDES. Maybe that is an elegant way to fix the problem? I can define a new machine in my layer with the modified values and then add the previous machine name to this overrides
Apr 29 20:00:20 <pumpernickel> I'm trying to add packages to an image.
Apr 29 20:00:28 <pumpernickel> Without using the local.conf, and failing miserably.
Apr 29 20:00:47 <pumpernickel> It's not clear to me which images you're allowed to inherit from, and which you aren't.
Apr 29 20:01:04 <pumpernickel> My understanding is that to add packages to an image, the proper way to do it is to create a new image.
Apr 29 20:01:19 <pumpernickel> So my layer has an xxx-image.bb
Apr 29 20:04:36 <pumpernickel> I added a package-group recipe as well.
Apr 29 20:04:57 <pumpernickel> Then, I try to add my packages into my image.bb recipe
Apr 29 20:05:44 <pumpernickel> FEATURE_PACKAGES_blah = "packagegroup-xxx"
Apr 29 20:06:09 <DS___> pumpernickel you can only inherit from classes (.bbclass) files
Apr 29 20:07:41 <DS___> Have you tried adding to IMAGE_INSTALL?
Apr 29 20:07:59 <DS___> IMAGE_INSTALL += "package_name"
Apr 29 20:08:32 <pumpernickel> I have not, but let's say I have core-image-minimal.
Apr 29 20:08:54 <pumpernickel> I want to add packages to that image.
Apr 29 20:09:19 <pumpernickel> It doesn't appear that I can inherit from it, how do I get that list of packages + my own?
Apr 29 20:10:38 <DS___> The way I do is to find the core-image-minimal.bb file, just copy and paste it into another image file, and then add from there.
Apr 29 20:11:09 <DS___> I'm not an yocto expert by any means (started using it been ~2 weeks), but that's how I found that core-image-minimal and core-image-base worked
Apr 29 20:11:30 <DS___> To me one inherited from the other, but they're two different images
Apr 29 20:11:50 <pumpernickel> Hmm, okay.
Apr 29 20:12:02 <pumpernickel> I suppose I need to go back through the manual exhaustively.
Apr 29 20:12:09 <DS___> Read the core-image-* files in the core layer
Apr 29 20:12:12 <pumpernickel> I've read big chunks of it, but not in a linear fashion.
Apr 29 20:12:16 <DS___> It's easier
Apr 29 20:12:41 <pumpernickel> Largely because I didn't understand a lot of what it was talking about on some sections until later.
Apr 29 20:12:41 <DS___> You'll see that none of them inherit from others. They all inherit from core-image, which is a bbclass
Apr 29 20:12:58 <DS___> That's the same feeling I still have sometimes when I start looking for stuff :)
Apr 29 20:13:18 <pumpernickel> I am very new to this as well.
Apr 29 20:13:39 <pumpernickel> Thanks for your help.
Apr 29 20:13:43 <pumpernickel> I may do exactly that.
Apr 29 20:13:51 <DS___> I've learned a lot by just going through the files and following the inherits, requires and all of that as well
Apr 29 20:13:56 <pumpernickel> Is it your understanding that this is the proper way to add packages to an image?
Apr 29 20:13:57 <DS___> Not only the manual
Apr 29 20:14:08 <pumpernickel> I mean, am I even going down the right path, or am I doing things in a bone-headed way?
Apr 29 20:14:36 <pumpernickel> That's the thing that bothers me the most.
Apr 29 20:14:47 <pumpernickel> I feel like I could be going completely against the spirit of the project.
Apr 29 20:14:54 <pumpernickel> Hmm, I suppose I need to do more of that.
Apr 29 20:14:57 <pumpernickel> I've done some.
Apr 29 20:15:01 <DS___> From what I've understood in the way images were built, that seems to be the way. I'm not sure if that's the proper way, I also would like an input from someone.
Apr 29 20:15:15 <DS___> I often come here asking about the best approach to do things I want to do
Apr 29 20:16:22 <pumpernickel> I've also looked into some of the core image.bb files.
Apr 29 20:16:35 <pumpernickel> Part of my issue there, was I didn't know what a lot of the stuff meant.
Apr 29 20:16:36 <DS___> But something that I keep in mind is to start doing stuff, that's the only way you'll learn more about it. Then you can go back and look for the best approaches to what you've done. That will require a lot of rewriting and redoing, but it's good for learning
Apr 29 20:17:04 <pumpernickel> I should also mention that I started working with poky 1.8, and was then forced to go back and use angstrom, which seems to be based on 1.6.
Apr 29 20:17:21 <pumpernickel> Yeah, haha
Apr 29 20:17:43 <pumpernickel> I must have rewritten my recipes 20 times!
Apr 29 20:17:56 <pumpernickel> I've actually considered writing a script to generate them from a template!
Apr 29 20:18:24 <DS___> The manuals have explanations for each of the variables used in yocto, so whenever you find something you don't understand, you can always look it up
Apr 29 20:18:32 <pumpernickel> In particular, I wrote them for 1.8, but going back, I a lot of recipes didn't work the same way.
Apr 29 20:19:03 <DS___> Gotcha. I've never worked on 1.6, so I can't say
Apr 29 20:19:15 <pumpernickel> I've tried to do that as well, until I realized that the layers are pretty much infinitely flexible, I didn't really grasp the implications of the variables.
Apr 29 20:20:24 <DS___> Yeah, I know what you mean
Apr 29 20:20:37 <pumpernickel> But I go into things like angstrom-image.bb, and it has lines: "[Match]\nName=en*\n\n[Network]\nDHCP=yes" etc
Apr 29 20:20:53 <pumpernickel> And I hadn't even seen those types of rules before.
Apr 29 20:21:04 <pumpernickel> Anyway, just venting a bit. Thanks again for your help.
Apr 29 20:21:05 <DS___> That is new to me
Apr 29 20:21:14 <DS___> You're welcome
Apr 29 20:21:50 <DS___> I've received a lot of help here, I'm just giving it back
Apr 29 20:21:51 <DS___> :)
Apr 29 20:22:04 <pumpernickel> I've been in and out of here on occasion.
Apr 29 20:22:20 <pumpernickel> I seem to have a problem catching people most days.
Apr 29 20:23:08 <pumpernickel> I think I end up in here too late in the day for most regulars.\
Apr 29 21:16:04 <otavio> ant_home: uh?!
Apr 29 21:21:39 <ant_home> hi
Apr 29 21:30:11 <darknighte> anyone know the current level of support for the Galileo 2 board?
Apr 29 21:30:27 <darknighte> in meta-intel-galileo, of course.
Apr 29 21:31:00 <darknighte> last commit was 3 mos ago.
Apr 29 21:35:38 <darknighte> warthog9: poke poke, you know the answer to my question ^^^ ?
Apr 29 21:36:39 <kergoth> fray: planning on re-submitting the split debug fs support now that we're past the 1.8 release?
Apr 29 21:41:36 <warthog9> darknighte: don't know sadly
Apr 29 21:41:59 <warthog9> darknighte: I can go poke some folks if you really want?
Apr 29 21:43:02 <darknighte> warthog9: sure, if you would.
Apr 29 21:44:32 <darknighte> warthog9: looks like brendan already responded to my email query, so nm.
Apr 29 22:31:07 <warthog9> darknighte: done and done :-)
Apr 29 22:57:48 * darknighte notices that galileo boad should be here by next week
Apr 29 22:57:51 <darknighte> woot
Apr 29 23:08:39 <Crofton|work> borad
Apr 30 02:23:50 <swap1712> hello everyone!
Apr 30 02:24:50 <swap1712> I have a question about debugging with Yocto Eclipse ADT using TCF. I'd appreciate if someone could take time to answer one of my questions
**** ENDING LOGGING AT Thu Apr 30 02:59:58 2015